From chrisw@nipltd.com Tue Aug 1 23:46:15 2000 From: chrisw@nipltd.com (chrisw@nipltd.com) Date: Tue, 1 Aug 2000 18:46:15 -0400 (EDT) Subject: [Python-bugs-list] Missing , not picked up by parser (PR#423) Message-ID: <20000801224615.149041D3AD@dinsdale.python.org> Full_Name: Chris Withers Version: 1.5.2 OS: WinNT/Linux Submission from: zuul.nipltd.com (194.193.44.21) I have something equivalent to this in my code: mylist = ['x','y' 'z'] (the real code has much longer contents, hence the line break ;-) I think this should throw a parse error 'cos there's a missing comma. What actually happens is it ends up as: mylist = ['x','yz'] which is _really_ non-intuitive. I spent a good few hours trying to find the source of an exception in the Squishdot product for Zope until I noticed this. I note that: mystring = 'x''y' is also legal, which I suspect is the roundabout source of this problem. Sure that should raise an error and only the following should give the result that that does: mystring = 'x'+'y' cheers, Chris From tim_one@email.msn.com Wed Aug 2 00:10:41 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 1 Aug 2000 19:10:41 -0400 Subject: [Python-bugs-list] Missing , not picked up by parser (PR#423) In-Reply-To: <20000801224615.149041D3AD@dinsdale.python.org> Message-ID: Sorry, but this is a documented feature: just as in C, adjacent string literals are concatenated at compile-time. You bumped up against the Dark Side of that. The Bright Side is, e.g., logfile.write("And here I need to write something " "to a log file that spills over a line " "of source code but I want it want to " "appear in the log as one line." "\n") It can't be made an error, as lots of code relies on it now. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of chrisw@nipltd.com > Sent: Tuesday, August 01, 2000 6:46 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Missing , not picked up by parser (PR#423) > > > Full_Name: Chris Withers > Version: 1.5.2 > OS: WinNT/Linux > Submission from: zuul.nipltd.com (194.193.44.21) > > > I have something equivalent to this in my code: > > mylist = ['x','y' > 'z'] > > (the real code has much longer contents, hence the line break ;-) > > I think this should throw a parse error 'cos there's a missing comma. > > What actually happens is it ends up as: > > mylist = ['x','yz'] > > which is _really_ non-intuitive. I spent a good few hours trying > to find the > source > of an exception in the Squishdot product for Zope until I noticed this. > > I note that: > mystring = 'x''y' > is also legal, which I suspect is the roundabout source of this problem. > > Sure that should raise an error and only the following should > give the result > that that does: > mystring = 'x'+'y' > > cheers, > > Chris > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From tim_one@email.msn.com Wed Aug 2 00:11:22 2000 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 1 Aug 2000 19:11:22 -0400 (EDT) Subject: [Python-bugs-list] Missing , not picked up by parser (PR#423) Message-ID: <20000801231122.D2C771D289@dinsdale.python.org> Sorry, but this is a documented feature: just as in C, adjacent string literals are concatenated at compile-time. You bumped up against the Dark Side of that. The Bright Side is, e.g., logfile.write("And here I need to write something " "to a log file that spills over a line " "of source code but I want it want to " "appear in the log as one line." "\n") It can't be made an error, as lots of code relies on it now. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of chrisw@nipltd.com > Sent: Tuesday, August 01, 2000 6:46 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] Missing , not picked up by parser (PR#423) > > > Full_Name: Chris Withers > Version: 1.5.2 > OS: WinNT/Linux > Submission from: zuul.nipltd.com (194.193.44.21) > > > I have something equivalent to this in my code: > > mylist = ['x','y' > 'z'] > > (the real code has much longer contents, hence the line break ;-) > > I think this should throw a parse error 'cos there's a missing comma. > > What actually happens is it ends up as: > > mylist = ['x','yz'] > > which is _really_ non-intuitive. I spent a good few hours trying > to find the > source > of an exception in the Squishdot product for Zope until I noticed this. > > I note that: > mystring = 'x''y' > is also legal, which I suspect is the roundabout source of this problem. > > Sure that should raise an error and only the following should > give the result > that that does: > mystring = 'x'+'y' > > cheers, > > Chris > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list From noreply@sourceforge.net Thu Aug 3 04:13:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 20:13:38 -0700 Subject: [Python-bugs-list] [Bug #110671] Tk-based widgets misbehave with dead keys (PR#376) Message-ID: <200008030313.UAA04788@bush.i.sourceforge.net> Bug #110671, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Tk-based widgets misbehave with dead keys (PR#376) Details: Jitterbug-Id: 376 Submitted-By: fstajano@uk.research.att.com Date: Thu, 29 Jun 2000 12:49:44 -0400 (EDT) Version: 1.6a2 OS: Windows 98 and 2000 This is a problem of the underlying widget set and not of Idle itself, but Idle is where I encountered it (I normally use Emacs), and since Python 1.6 is the unicode version I suppose it's worth looking into anyway (what good is it to have international chars if you can't input them ;-)). If, on Windows, you use a keyboard layout with dead keys, such as "United States - International", then Idle does not respond properly to dead keys. In particular, double-quote comes out as single-quote; single-quote comes out as space; and accented characters come out as non-accented. The lack of support for the accented chars is a minor nuisance, but the problems with quotes are a major one -- Idle is almost unusable under these circumstances. Not as bad as Pythonwin, though, which just crashes. [As you will know, the US-I keyboard defines things like single-quote and double-quote as dead keys so that one can produce accents and umlauts respectively by following the dead key with the appropriate vowel. To produce a double-quote on its own, you have to press double-quote followed by space.] ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110671&group_id=5470 From noreply@sourceforge.net Thu Aug 3 07:10:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 2 Aug 2000 23:10:47 -0700 Subject: [Python-bugs-list] [Bug #110613] makesetup support for RPATH (PR#202) Message-ID: <200008030610.XAA03098@delerium.i.sourceforge.net> Bug #110613, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 5 Summary: makesetup support for RPATH (PR#202) Details: Jitterbug-Id: 202 Submitted-By: aa8vb@yahoo.com Date: Fri, 11 Feb 2000 07:12:28 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 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 ==================================================================== Audit trail: Wed Feb 23 21:30:21 2000 guido changed notes Wed Feb 23 21:30:21 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-02 23:10 By: fdrake Comment: The current CVS version of makesetup appears to handle -rpath and -R, but not --rpath. Is neither of the alternatives sufficient for FreeBSD? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110613&group_id=5470 From Marc.Haesen@lhs.be Thu Aug 3 12:37:07 2000 From: Marc.Haesen@lhs.be (Marc.Haesen@lhs.be) Date: Thu, 3 Aug 2000 07:37:07 -0400 (EDT) Subject: [Python-bugs-list] Memory leackage in PyArg_ParseTupleAndKeywords (PR#424) Message-ID: <20000803113707.1CF9D1CD16@dinsdale.python.org> Full_Name: Marc Haesen Version: 1.5.2 OS: Submission from: uu194-7-57-204.unknown.uunet.be (194.7.57.204) On line 953 of the file getargs.c a call is made to the PyMapping_GetItemString routine wich returns a new reference. This new reference however is not decremented afterwards, resulting in a memory leack. From noreply@sourceforge.net Thu Aug 3 13:17:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 05:17:02 -0700 Subject: [Python-bugs-list] [Bug #110663] getpass() echo password input (PR#359) Message-ID: <200008031217.FAA20617@bush.i.sourceforge.net> Bug #110663, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Wont Fix Bug Group: Platform-specific Priority: 2 Summary: getpass() echo password input (PR#359) Details: Jitterbug-Id: 359 Submitted-By: harishbk@inf.com Date: Fri, 16 Jun 2000 03:46:58 -0400 (EDT) Version: 1.5.2 OS: OSF1 version 4.0f code: #! /usr/local/bin/python import getpass pas=getpass.getpass() when it is run password : harish it is echoing password input. How can we avoid echoing it. ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: "M.-A. Lemburg" Subject: Re: [Python-bugs-list] getpass() echo password input (PR#359) Date: Fri, 16 Jun 2000 10:03:55 +0200 harishbk@inf.com wrote: > > Full_Name: harish > Version: 1.5.2 > OS: OSF1 version 4.0f > Submission from: (NULL) (202.54.39.82) > > code: > > #! /usr/local/bin/python > > import getpass > pas=getpass.getpass() > > when it is run > password : harish > > it is echoing password input. How can we avoid echoing it. You will need to compile Python with termios support enabled to have getpass() turn off echoing. (Edit Modules/Setup and rerun 'make install'.) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110663&group_id=5470 From noreply@sourceforge.net Thu Aug 3 13:18:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 05:18:33 -0700 Subject: [Python-bugs-list] [Bug #110661] cgi parsing of query strings (PR#356) Message-ID: <200008031218.FAA14039@delerium.i.sourceforge.net> Bug #110661, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: cgi parsing of query strings (PR#356) Details: Jitterbug-Id: 356 Submitted-By: mredar@yahoo.com Date: Tue, 13 Jun 2000 16:05:59 -0400 (EDT) Version: 1.5.2 OS: linux I am currently starting to use the cgi module for python. In general it's quite nice, I love the builtin "test" function--very handy. I do have a quibble with the handling of query strings by the parser. In the HTML 4 specification, appendix B it is stated: B.2.2 Ampersands in URI attribute values The URI that is constructed when a form is submitted may be used as an anchor-style link (e.g., the href attribute for the A element). Unfortunately, the use of the "&" character to separate form fields interacts with its use in SGML attribute values to delimit character entity references. For example, to use the URI "http://host/?x=1&y=2" as a linking URI, it must be written or . We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner. The recommended handling of ';' as field delimiters is not implemented in this module. Do you have any plans to implement this feature? My current company is going to use the ';' separator and it works with other cgi packages (perl & java servlets). I'd love to use python, but this is a stumbling block. Thanks, Mark ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110661&group_id=5470 From noreply@sourceforge.net Thu Aug 3 13:20:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 05:20:56 -0700 Subject: [Python-bugs-list] [Bug #110658] W2k and pyton 1.5 (PR#353) Message-ID: <200008031220.FAA20775@bush.i.sourceforge.net> Bug #110658, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Fixed Bug Group: Not a Bug Priority: 3 Summary: W2k and pyton 1.5 (PR#353) Details: Jitterbug-Id: 353 Submitted-By: giusedia@libero.it Date: Sun, 11 Jun 2000 18:19:32 -0400 (EDT) Version: 1.5 OS: W2k When installing pyton 1.5 in my w2k, i noticed an error message when starting IDLE(Pyton gui)as admin.The error was some dll not found, tk80.dll and tcl80.dll, in the c:\programmi\python\dlls dir. The program then continued normally. I fixed it copying them there and now starts normally. But IDLE(Pyton gui)keeps not starting at all while in user mode.Bye ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-03 05:20 By: twouters Comment: This problem is not specific to Windows 2000. For Python 1.5.2 and earlier, you need to install Tcl/Tk yourself, before installing Python. Just as the install instructions tells you to. This will be 'fixed' in 1.6 and later, which include a Tcl/Tk installer. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110658&group_id=5470 From noreply@sourceforge.net Thu Aug 3 13:43:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 05:43:51 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008031243.FAA21534@bush.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 4 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Thu Aug 3 13:50:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 05:50:20 -0700 Subject: [Python-bugs-list] [Bug #110627] Floating point numbers (PR#277) Message-ID: <200008031250.FAA21706@bush.i.sourceforge.net> Bug #110627, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: 3rd Party Priority: 3 Summary: Floating point numbers (PR#277) Details: Jitterbug-Id: 277 Submitted-By: gellsmore@yahoo.com Date: Wed, 5 Apr 2000 17:00:09 -0400 (EDT) Version: Python CE 1.0b1 OS: Windows CE H/PC 3.01 pro Floating point answer objects not returned correctly >>>3.1 g All floats return g but will work in scenario below where floats form part of the expression but not the answer object >>>int(3.1/2) 1 this works. ==================================================================== Audit trail: Mon May 22 17:49:40 2000 guido changed notes Mon May 22 17:49:40 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-03 05:50 By: twouters Comment: Hm, Python CE 1.0b1 ? I'm not sure if that's an old version of Python ported to the CE, or a recent version of Python ported to the CE with a new version number. In any case, I dont believe the CE port is being maintained by the core Python group, so I don't think we can do much about it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110627&group_id=5470 From noreply@sourceforge.net Thu Aug 3 15:27:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 07:27:36 -0700 Subject: [Python-bugs-list] [Bug #110832] urljoin() bug with odd no of '..' (PR#194) Message-ID: <200008031427.HAA18121@delerium.i.sourceforge.net> Bug #110832, was updated on 2000-Aug-01 14:13 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Feature Request Priority: 6 Summary: urljoin() bug with odd no of '..' (PR#194) Details: Jitterbug-Id: 194 Submitted-By: DrMalte@ddd.de Date: Sun, 30 Jan 2000 19:40:45 -0500 (EST) Version: 1.5.2 and 1.4 OS: Linux While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing . The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) ==================================================================== Audit trail: Mon Feb 07 12:35:35 2000 guido changed notes Mon Feb 07 12:35:35 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:13 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Date: Mon, 31 Jan 2000 12:28:55 -0500 Thanks for your bug report and fix. I agree with your diagnosis. Would you please be so kind as to resend your patch with the legal disclaimer from http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: none Comment: Patch being considered. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110832&group_id=5470 From noreply@sourceforge.net Thu Aug 3 16:20:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 08:20:52 -0700 Subject: [Python-bugs-list] [Bug #110672] pythonlib.a makes SIGSEGV with LD_PRELOAD variable (PR#378) Message-ID: <200008031520.IAA19909@delerium.i.sourceforge.net> Bug #110672, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: pythonlib.a makes SIGSEGV with LD_PRELOAD variable (PR#378) Details: Jitterbug-Id: 378 Submitted-By: epx@conectiva.com Date: Fri, 30 Jun 2000 16:10:23 -0400 (EDT) Version: 1.5.2 OS: Linux glibc 2.1.3 kernel 2.2.16 Modules/posixmodule,c, function convertenviron(), uses a dirty trick when parsing POSIX environment variables. All variables are formatted as = Example: KDEDIR=/usr Python changes '=' to '\0' for a moment while parsing, in the line *p = '\0' But, if LD_PRELOAD variable is present, it SIGSEGVs in this command. I guess this variable is in a mprotect()ed page for security reasons. The environment variable parser should strdup() the variables or change the parsing algorithm so it no longer writes directly the environment var. array. ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-03 08:20 By: twouters Comment: Fixed by revision 2.113 of posixmodule.c, checked in by Guido. Code now uses PyString_FromStringAndSize to 'substring' the environment variables, rather than writing \0's in them. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110672&group_id=5470 From noreply@sourceforge.net Thu Aug 3 16:38:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 08:38:57 -0700 Subject: [Python-bugs-list] [Bug #110636] prefix directory (PR#293) Message-ID: <200008031538.IAA20458@delerium.i.sourceforge.net> Bug #110636, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 3 Summary: prefix directory (PR#293) Details: Jitterbug-Id: 293 Submitted-By: kajiyama@grad.sccs.chukyo-u.ac.jp Date: Wed, 12 Apr 2000 15:14:10 -0400 (EDT) Version: 1.6a2 OS: Plamo Linux 1.3 (Repost: excuse me for annoyance) The installation procedure ("make install") fails if the prefix directory specified with configure's --prefix option does not exist. Manually making the prefix directory is sufficient, but automatic creation may be more preferable. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-03 08:38 By: twouters Comment: Yup, this is a problem. This could be fixed by using mkdir's '-p' flag, in the Makefile. However, I'm not entirely sure how portable the -p flag is. The other solution, manually checking each parent directory and creating them when necessary, is a lot more work. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110636&group_id=5470 From noreply@sourceforge.net Thu Aug 3 17:00:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 09:00:10 -0700 Subject: [Python-bugs-list] [Bug #110707] does not compile under BSDI (PR#57) Message-ID: <200008031600.JAA21224@delerium.i.sourceforge.net> Bug #110707, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: does not compile under BSDI (PR#57) Details: Jitterbug-Id: 57 Submitted-By: jital@knoggin.com Date: Fri, 20 Aug 1999 04:18:04 -0400 (EDT) Version: py152 OS: BSDI IServer seems to think it is a NeXT arch or something $ ./configure --prefix=/usr/home/knoggin/usr/local/ --exec-prefix=/usr/home/knoggin/usr/local/ creating cache ./config.cache checking MACHDEP... bsdos3 checking CCC... checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... gcc -D_HAVE_BSDI -E checking for AIX... no checking for minix/config.h... no checking whether gcc -D_HAVE_BSDI accepts -OPT:Olimit=0... no checking whether gcc -D_HAVE_BSDI accepts -Olimit 1500... no checking for C preprocessor type... ansi checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 4 checking size of void *... 4 checking for long long support... yes checking size of long long... 8 checking size of off_t... 8 checking whether to enable large file support... yes checking for --with-next-framework... no checking for --with-dyld... required for framework build checking SO... .so checking LDSHARED... ld checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for socket in -lnet... no checking for --with-libs... no checking for --with(out)-readline... not specified. checking for --with-dec-threads... no checking for --with-threads... no checking for --with-thread... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for alarm... yes checking for chown... yes checking for clock... yes checking for dlopen... yes checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... no checking for ftime... no checking for ftruncate... yes checking for getpeername... yes checking for getpgrp... yes checking for getpid... yes checking for getpwent... yes checking for gettimeofday... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for nice... yes checking for pause... yes checking for plock... no checking for pthread_init... yes checking for putenv... yes checking for readlink... yes checking for select... yes checking for setgid... yes checking for setlocale... yes checking for setuid... yes checking for setsid... yes checking for setpgid... yes checking for setpgrp... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... no checking for strftime... yes checking for strptime... no checking for symlink... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for timegm... no checking for times... yes checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... no checking for ftell64... no checking for ftello... no checking for statvfs... no checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... (cached) yes checking for setpgrp... (cached) yes checking for gettimeofday... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... no checking for gethostbyname... yes checking for __fpu_control in -lieee... no checking for --with-fpectl... checking for --with-libm=STRING... default LIBM="- lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for hypot... (cached) yes checking for genuine getopt... yes checking what malloc(0) returns... nonnull updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.thread creating config.h pcvendor:~/usr/local/src/Python-1.5.2 $ make (cd Modules; make -f Makefile.pre Makefile) cp ./Setup.in Setup echo "# Edit this file for local setup changes" >Setup.local rm -f ../libpython1.5.a /bin/sh ./makesetup Setup.thread Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmo dule.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule. o timemodule.o operator.o fcntlmodule.o pwdmodule.o grpmodule.o selectmodu le.o socketmodule.o errnomodule.o md5module.o md5c.o shamodule.o rotormodul e.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o ge tpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo y es >hassignal; break; fi; done cd Parser ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local /" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c gcc -D_HAVE_BSDI -g -O2 pgenmain.o acceler.o grammar1.o listnode.o node.o parse r.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -ldl -o pgen gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cd Objects ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cd Python ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"bsdos3"' ./getplatform.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c ./importdl.c:269: mach-o/dyld.h: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. ==================================================================== Audit trail: Mon Aug 30 12:40:26 1999 guido changed notes Mon Aug 30 12:40:26 1999 guido moved from incoming to irreproducible Tue Oct 19 23:20:49 1999 guido sent reply 1 Tue Oct 19 23:21:36 1999 guido changed notes Tue Oct 19 23:21:36 1999 guido moved from irreproducible to open Tue Oct 19 23:30:25 1999 guido changed notes Tue Oct 19 23:30:25 1999 guido moved from open to platformbug Follow-Ups: Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: does not compile under BSDI (PR#57) Date: Tue Oct 19 23:20:49 1999 This same bug was reported by someone else for the same platform. We arrived at the work-around of deleting the line #define WITH_DYLD from the config.h generated by the configure script. If you are still experiencing problems building Python, please try this. --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] does not compile under BSDI (PR#57) Date: Fri, 20 Aug 1999 07:57:10 -0400 > Full_Name: John Ital > Version: py152 > OS: BSDI IServer > > seems to think it is a NeXT arch or something > [...] > gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c > ./importdl.c:269: mach-o/dyld.h: No such file or directory > *** Error code 1 Very strange. I've never seen this before. It appears that somehow USE_DYLD is defined at that point, which can only happen if WITH_DYLD is defined, which can only happen if you specify --with-next-framework or --with-dyld on the configure command line, which you didn't. Perhaps you have a buggy preprocessor that is confused by the tangle of #ifdefs in importdl.c? I don't know how to help you; I know Python has been built successfully on bsdos3 before, so I'm guessing it's something in your setup, not a Python bug. If you need more help, please ask a newsgroup -- either comp.lang.python or a BSD specific one. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: Work-around: if you delete #define WITH_DYLD from config.h, the build succeeds. ------------------------------------------------------- Date: 2000-Aug-03 09:00 By: twouters Comment: For the record, I cannot reproduce this on the BSDI 3.1 systems we still have lying around. It *might* have been specific to BSDI 3.0, which we no longer have (for various reasons, like y2k bugs ;) and I've heard similar (but not the same) reports about BSD/OS running under a 'virtual' machine. However, I've never seen or heard about those 'virtual' BSD/OSes, other than in that c.l.py posting. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110707&group_id=5470 From noreply@sourceforge.net Thu Aug 3 17:17:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 09:17:00 -0700 Subject: [Python-bugs-list] [Bug #110599] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <200008031617.JAA28389@bush.i.sourceforge.net> Bug #110599, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Details: Jitterbug-Id: 102 Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Date: Mon, 11 Oct 1999 13:00:07 +0200 Version: None OS: None 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 **************************************************************************** ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:05 By: none Comment: From: Jeremy Hylton Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT) >>>>> "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 ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 09:19:44 +0200 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 ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 08:57:25 -0400 > 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/) ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 16:34:39 +0200 >... >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 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110599&group_id=5470 From noreply@sourceforge.net Thu Aug 3 20:04:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 12:04:16 -0700 Subject: [Python-bugs-list] [Bug #110636] prefix directory (PR#293) Message-ID: <200008031904.MAA01775@bush.i.sourceforge.net> Bug #110636, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Wont Fix Bug Group: None Priority: 3 Summary: prefix directory (PR#293) Details: Jitterbug-Id: 293 Submitted-By: kajiyama@grad.sccs.chukyo-u.ac.jp Date: Wed, 12 Apr 2000 15:14:10 -0400 (EDT) Version: 1.6a2 OS: Plamo Linux 1.3 (Repost: excuse me for annoyance) The installation procedure ("make install") fails if the prefix directory specified with configure's --prefix option does not exist. Manually making the prefix directory is sufficient, but automatic creation may be more preferable. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-03 08:38 By: twouters Comment: Yup, this is a problem. This could be fixed by using mkdir's '-p' flag, in the Makefile. However, I'm not entirely sure how portable the -p flag is. The other solution, manually checking each parent directory and creating them when necessary, is a lot more work. ------------------------------------------------------- Date: 2000-Aug-03 12:04 By: gvanrossum Comment: This intentional. The reason is that "make install" is often done as root. If you make a typo and accidentally specify an erroneous prefix, it would silently create that for you! In nurmal use, prefix is /usr or /usr/local so it should always exist. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110636&group_id=5470 From noreply@sourceforge.net Thu Aug 3 21:00:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 13:00:38 -0700 Subject: [Python-bugs-list] [Bug #110830] Syntax (PR#177) Message-ID: <200008032000.NAA29692@delerium.i.sourceforge.net> Bug #110830, was updated on 2000-Aug-01 14:12 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: Later Bug Group: Feature Request Priority: 1 Summary: Syntax (PR#177) Details: Jitterbug-Id: 177 Submitted-By: simonb@logical.co.za Date: Tue, 11 Jan 2000 05:17:37 -0500 (EST) Version: 1-5-2 OS: NT 4.0 Hi there I don't know if this is a bug, or is intentional behaviour for a specific reason. The following code produces a syntax error about the continue not being within a looping structure rather than a prefectly silly infinite loop... while 1: try: continue except: pass where the following works as one would expect... while 1: try: raise 1 except: continue I figure that there is more likely a sane reason for this behaviour than being a bug, but I am curious. Thanks Simon ==================================================================== Audit trail: Wed Jan 12 18:11:45 2000 guido changed notes Wed Jan 12 18:11:45 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:12 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] Syntax (PR#177) Date: Tue, 11 Jan 2000 12:10:17 -0500 [Simon Barratt, putting "continue" in a "try" block] > I don't know if this is a bug, or is intentional behaviour > for a specific reason. Actually, it's a bit of both . See the Language Reference Manual's section on the "continue" statement, particularly the footnote: The restriction on occurring in the try clause is implementer's laziness and will eventually be lifted. It's been this way (and documented) forever; it's simply hard to implement given the current structure of the interpreter loop. Rest assured there's nothing *conceptually* wrong with putting continue in a try! It's simply an implementation restriction; the error msg should probably make that clearer. IIRC, JPython doesn't have this restriction. "Someday" it will get repaired in CPython too. ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: It's a zero-priority bug (i.e. not likely to be fixed). ------------------------------------------------------- Date: 2000-Aug-03 13:00 By: twouters Comment: Like the bot said, low priority 'to be fixed' bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110830&group_id=5470 From noreply@sourceforge.net Thu Aug 3 22:50:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 3 Aug 2000 14:50:30 -0700 Subject: [Python-bugs-list] [Bug #110640] 1.6a2 issues with int/long on 64bit platforms - eg stringobject (PR#306) Message-ID: <200008032150.OAA07476@bush.i.sourceforge.net> Bug #110640, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: 1.6a2 issues with int/long on 64bit platforms - eg stringobject (PR#306) Details: Jitterbug-Id: 306 Submitted-By: mark.favas@per.dem.csiro.au Date: Mon, 24 Apr 2000 19:26:25 -0400 (EDT) Version: 1.6a2 CVS of 25 April OS: DEC Alpha, Tru64 Unix 4.0F There seems to be issues (and perhaps lurking cans of worms) on 64-bit platforms where sizeof(long) != sizeof(int). For example, the CVS version of 1.6a2 of 25 April fails the UserString regression test. The tests fail as follows (verbose set to 1): abcabcabc.count(('abc',)) no 'abcabcabc' 3 <> 2 abcabcabc.count(('abc', 1)) no 'abcabcabc' 2 <> 1 abcdefghiabc.find(('abc', 1)) no 'abcdefghiabc' 9 <> -1 abcdefghiabc.rfind(('abc',)) no 'abcdefghiabc' 9 <> 0 abcabcabc.rindex(('abc',)) no 'abcabcabc' 6 <> 3 abcabcabc.rindex(('abc', 1)) no 'abcabcabc' 6 <> 3 These tests are failing because the calls from the UserString methods to the underlying string methods are setting the default value of the end-of-string parameter to sys.maxint, which is defined as LONG_MAX (9223372036854775807), whereas the string methods in stringobject.c are using ints and expecting them to be no larger than INT_MAX (2147483647). Thus the end-of-string parameter becomes -1 in the default case. The size of an int on my platform is 4, and the size of a long is 8, so the "natural size of a Python integer" should be 8, by my understanding. The obvious fix is to change stringobject.c to use longs, rather than ints, but the problem might be more widespread than that. INT_MAX is used in unicodeobject.c, pypcre.c, _sre.c, stropmodule.c, and ceval.c as well as stringobject.c. Some of these look as though LONG_MAX should have been used (variables compared to INT_MAX are longs, but I am not confident enough to submit patches for them... Mark ==================================================================== Audit trail: Mon May 22 17:22:20 2000 guido changed notes Mon May 22 17:22:20 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-02 04:07 By: twouters Comment: Most likely fixed by the 64-bit-platform fixes from Trent Mick and others. Mark, is this still a problem ? ------------------------------------------------------- Date: 2000-Aug-03 14:50 By: tmick Comment: This was fixed a while back.Relevant email threads: Guido raises Mark's bug report and MAL,Guido,Tim, and I discuss it: http://www.python.org/pipermail/python-dev/2000-April/010456.html http://www.python.org/pipermail/python-dev/2000-May/010514.html MAL's silent truncation proposed patch (Guido turned it down): http://www.python.org/pipermail/patches/2000-May/000588.html My proposed patch to correct the string slice-semantic functions to actually correctly accept and handle all integral values. http://www.python.org/pipermail/patches/2000-May/000608.html And my patches getting checked in for string- and unicode- object.c: http://www.python.org/pipermail/python-checkins/2000-May/005562.html http://www.python.org/pipermail/python-checkins/2000-May/005573.html Mark Favas (via private email), the bug submitter, verified through provate email that the bug seems to be fixed for him as well. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110640&group_id=5470 From millionary@mail.ru Fri Aug 4 02:47:33 2000 From: millionary@mail.ru (millionary@mail.ru) Date: Thu, 3 Aug 2000 21:47:33 -0400 (EDT) Subject: [Python-bugs-list] =?windows-1251?Q?=C1=E8=E7=ED=E5=F1-=C2=EE=EB=ED=E0_2000?= (PR#425) Message-ID: <20000804014733.DA1E81CD61@dinsdale.python.org> Çàáóäüòå âñå, ÷òî Âû ñëûøàëè ðàíüøå î áèçíåñå â Èíòåðíåòå. Ïðåäëàãàåì Âàì áèçíåñ "Íîâîé Âîëíû". Ïîëíàÿ èëè ÷àñòè÷íàÿ çàíÿòîñòü â Èíòåðíåòå. - Âàøà çàäà÷à ïðîäàâàòü èíôîðìàöèþ ÷åðåç E-mail - Èíôîðìàöèÿ - ýòî òîâàð XXI âåêà - Âû èìååòå áîëåå 40.000.000 ïîòåíöèàëüíûõ êëèåíòîâ (ïî ìíåíèþ ãàçåòû "Êîììåðñàíò" îò 15 ìàÿ 2000 ã.) - Âàøà ïðèáûëü ñîñòàâèò îò $700 äî $5.000 â ìåñÿö Ïîæàëóéñòà, åñëè Âû çàèíòåðåñîâàëèñü, ïîëó÷èòå ïîëíóþ èíôîðìàöèþ ïî http://more.at/report From noreply@sourceforge.net Fri Aug 4 14:11:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 06:11:42 -0700 Subject: [Python-bugs-list] [Bug #110656] IDLE goto file/line (PR#352) Message-ID: <200008041311.GAA28640@delerium.i.sourceforge.net> Bug #110656, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 5 Summary: IDLE goto file/line (PR#352) Details: Jitterbug-Id: 352 Submitted-By: gpk@bell-labs.com Date: Fri, 9 Jun 2000 22:45:05 -0400 (EDT) Version: 1.6 CVS today OS: Solaris 2.6 When using IDLE's shell window Debug->Go to file/line, you have to be overly careful what you select. Specifically, if you select a region that contains a newline, IDLE won't be able to find a file and line number. For example, if you select v-- from there File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in __str__ ^-- to there (i.e. 2 characters in, on the following line), you will get the following error message: "No special line: X the line you point to doesn't look like a file name followed by a line number." That is unfortunate, as it's really convenient to make a quick flick down from one line to the next, to select a complete line. By the way, the error box requires you to click "OK". That's a bug. It isn't OK. It's a crime against the King's English, committed by the minions of Bill Gates. You should not be following their lead. ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110656&group_id=5470 From noreply@sourceforge.net Fri Aug 4 14:12:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 06:12:02 -0700 Subject: [Python-bugs-list] [Bug #110659] IDLE-0.5 copy command (PR#354) Message-ID: <200008041312.GAA02802@bush.i.sourceforge.net> Bug #110659, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 5 Summary: IDLE-0.5 copy command (PR#354) Details: Jitterbug-Id: 354 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 10:05:35 -0400 (EDT) Version: 1.6a2+ OS: Solaris sparc 2.6 Alt-w is advertised to copy the selected text. It doesn't. It pops up the 'window' menu. However, even if you are in the 'edit' menu, alt-w apparently does nothing. I can select text, do alt-E alt-W, move the pointer, then do ctrl-Y, and nothing pops up. By the way, 'ctl-U ctl-U ctl-S' is an absurdly long sequence for something as common as searching for text. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110659&group_id=5470 From noreply@sourceforge.net Fri Aug 4 14:13:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 06:13:03 -0700 Subject: [Python-bugs-list] [Bug #110660] IDLE-0.5 ctrl-F5 (PR#355) Message-ID: <200008041313.GAA02817@bush.i.sourceforge.net> Bug #110660, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 5 Summary: IDLE-0.5 ctrl-F5 (PR#355) Details: Jitterbug-Id: 355 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 11:30:14 -0400 (EDT) Version: yesterday's CVS OS: Solaris 2.6 If you type ctrl-f5 to run a script twice in sucession, IDLE will incorrectly pop up a window saying "Not Saved. Please Save First." If you save (even though you haven't changed anything, and even though there are no asterisks around the window title), then ctrl-f5 will work again. This *doesn't* happen if you run the script twice in succession from the menu. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 13 Jun 2000 11:55:09 -0400 Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under Windows, but darned hard to see why that would matter. Can anyone else try this under Solaris 2.6? May have something to do with the specific script you're running, Greg; e.g., does it happen if the script file contains just print "Hi!" ? > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > Sent: Tuesday, June 13, 2000 11:30 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > Full_Name: Greg Kochanski > Version: yesterday's CVS > OS: Solaris 2.6 > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > If you type ctrl-f5 to run a script twice in sucession, > IDLE will incorrectly pop up a window saying > "Not Saved. Please Save First." > > If you save (even though you haven't changed anything, > and even though there are no asterisks around the window > title), then ctrl-f5 will work again. > > This *doesn't* happen if you run the script twice in > succession from the menu. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 16:42:57 -0500 I think I understand this. It's happened to me too. Pressing ^F5 changes the focus to the PyShell window. Pressing ^F5 again then indeed complains about that window being unsaved. --Guido van Rossum (home page: http://www.python.org/~guido/) [Tim] > Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under > Windows, but darned hard to see why that would matter. Can anyone else try > this under Solaris 2.6? May have something to do with the specific script > you're running, Greg; e.g., does it happen if the script file contains just > > print "Hi!" > > ? > > > -----Original Message----- > > From: python-bugs-list-admin@python.org > > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > > Sent: Tuesday, June 13, 2000 11:30 AM > > To: python-bugs-list@python.org > > Cc: bugs-py@python.org > > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > > > > Full_Name: Greg Kochanski > > Version: yesterday's CVS > > OS: Solaris 2.6 > > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > > > > If you type ctrl-f5 to run a script twice in sucession, > > IDLE will incorrectly pop up a window saying > > "Not Saved. Please Save First." > > > > If you save (even though you haven't changed anything, > > and even though there are no asterisks around the window > > title), then ctrl-f5 will work again. > > > > This *doesn't* happen if you run the script twice in > > succession from the menu. > > > > > > > > _______________________________________________ > > Python-bugs-list maillist - Python-bugs-list@python.org > > http://www.python.org/mailman/listinfo/python-bugs-list > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: Greg Kochanski Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 17:25:37 -0400 Guido van Rossum wrote: > > I think I understand this. It's happened to me too. Pressing ^F5 > changes the focus to the PyShell window. Pressing ^F5 again then > indeed complains about that window being unsaved. > > --Guido van Rossum (home page: http://www.python.org/~guido/) Ah. Sure enough. Perhaps the best thing to do is just to have the little error message explain which window is unsaved. Include the title of the unsaved window in the error box, maybe. I'd be happy to send a patch, but the paperwork would be terrible... ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 18:10:35 -0500 > > I think I understand this. It's happened to me too. Pressing ^F5 > > changes the focus to the PyShell window. Pressing ^F5 again then > > indeed complains about that window being unsaved. > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > Ah. Sure enough. Perhaps the best thing to do > is just to have the little error message explain > which window is unsaved. Include the title > of the unsaved window in the error box, maybe. > > I'd be happy to send a patch, but the paperwork > would be terrible... No need for paperwork, just the disclaimer text. But I think the better patch would be to make PyShell a special case and make it rerun the last window that had the focus. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110660&group_id=5470 From noreply@sourceforge.net Fri Aug 4 14:23:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 06:23:00 -0700 Subject: [Python-bugs-list] [Bug #110661] cgi parsing of query strings (PR#356) Message-ID: <200008041323.GAA28986@delerium.i.sourceforge.net> Bug #110661, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: cgi parsing of query strings (PR#356) Details: Jitterbug-Id: 356 Submitted-By: mredar@yahoo.com Date: Tue, 13 Jun 2000 16:05:59 -0400 (EDT) Version: 1.5.2 OS: linux I am currently starting to use the cgi module for python. In general it's quite nice, I love the builtin "test" function--very handy. I do have a quibble with the handling of query strings by the parser. In the HTML 4 specification, appendix B it is stated: B.2.2 Ampersands in URI attribute values The URI that is constructed when a form is submitted may be used as an anchor-style link (e.g., the href attribute for the A element). Unfortunately, the use of the "&" character to separate form fields interacts with its use in SGML attribute values to delimit character entity references. For example, to use the URI "http://host/?x=1&y=2" as a linking URI, it must be written or . We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner. The recommended handling of ';' as field delimiters is not implemented in this module. Do you have any plans to implement this feature? My current company is going to use the ';' separator and it works with other cgi packages (perl & java servlets). I'd love to use python, but this is a stumbling block. Thanks, Mark ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110661&group_id=5470 From noreply@sourceforge.net Fri Aug 4 14:58:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 06:58:31 -0700 Subject: [Python-bugs-list] [Bug #110681] memory leak in loops (PR#398) Message-ID: <200008041358.GAA30094@delerium.i.sourceforge.net> Bug #110681, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: memory leak in loops (PR#398) Details: Jitterbug-Id: 398 Submitted-By: ingo.adler@synacon.ch Date: Fri, 14 Jul 2000 05:10:25 -0400 (EDT) Version: 1.5.2 OS: win nt I have a simple loop, which produces memory leaks at every call (36 bytes): { Py_SetProgramName("pythontest.exe"); Py_Initialize(); initxmodulec(); PyRun_SimpleString("print \"... Python started ...\""); PyRun_SimpleString("import xmodule"); PyRun_SimpleString("from xmodule import *"); // The Loop PyRun_SimpleString( "y = Y()\n" "for i in range(1000):\n" "\tx = y.getX()\n" "\tx.getNumber()\n" ); PyRun_SimpleString("print \"... Python finished ...\""); Py_Finalize(); } X and Y are my classes implemented in C++, connected to Python via Swig Shadow Classes: class X { public: float getNumber() { return 12.2; } }; class Y { X* pX; public: Y() { pX = new X; } ~Y() { delete pX; } X* getX() { return pX; } }; The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same problem with swig1.1). I tested the application with "CodeGuard", which shows the memory leaks. For every call in the loop there is an entry like this (I translated it to English): Error. 0x300010 (Thread 0x013B): resource leak: memory block (0x15422F0) was never released memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc call stack: 0x0045ED5D(=pythontest.exe:0x01:05DD5D) G:\Projects\src\fortuna\Python\Objects\stringobject.c#145 0x00401EFD(=pythontest.exe:0x01:000EFD) G:\Projects\src\fortuna\test\xmodule_wrap.c#769 0x0040255D(=pythontest.exe:0x01:00155D) G:\Projects\src\fortuna\test\xmodule_wrap.c#941 0x0041BA79(=pythontest.exe:0x01:01AA79) G:\Projects\src\fortuna\Python\Python\ceval.c#2359 0x0041B912(=pythontest.exe:0x01:01A912) G:\Projects\src\fortuna\Python\Python\ceval.c#2324 0x0040EE3E(=pythontest.exe:0x01:00DE3E) G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12 The Code for line 941: #define Y_getX(_swigobj) (_swigobj->getX()) static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) { Y *_arg0; PyObject *_resultobj,*_argo0=0; X *_result; self = self; if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) return NULL; if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return NULL; _result = (X *)Y_getX(_arg0); /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p); return _resultobj; } The Code for line 769: SWIGSTATICRUNTIME(PyObject *) SWIG_NewPointerObj(void *ptr, _swig_type_info *type) { char result[512]; PyObject *robj; if (!ptr) { Py_INCREF(Py_None); return Py_None; } #ifdef SWIG_COBJECT_TYPES robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL); #else SWIG_MakePtr(result,ptr,type); /*769*/ robj = PyString_FromString(result); #endif return robj; } Ingo Adler ==================================================================== Audit trail: Tue Jul 25 07:27:50 2000 guido changed notes Tue Jul 25 07:27:50 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: "M.-A. Lemburg" Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 11:22:51 +0200 ingo.adler@synacon.ch wrote: > > Full_Name: ingo adler > Version: 1.5.2 > OS: win nt > Submission from: megazh-d-201.agrinet.ch (212.28.158.201) > > I have a simple loop, which produces memory leaks at every call (36 bytes): > > { > Py_SetProgramName("pythontest.exe"); > Py_Initialize(); > > initxmodulec(); > > PyRun_SimpleString("print \"... Python started ...\""); > > PyRun_SimpleString("import xmodule"); > PyRun_SimpleString("from xmodule import *"); > > // The Loop > PyRun_SimpleString( > "y = Y()\n" > "for i in range(1000):\n" > "\tx = y.getX()\n" > "\tx.getNumber()\n" Could be that SWIG doesn't get a chance to cleanup the shadow object for x and y. Try adding del x,y as final script line. Note that SWIG uses Python strings to represent pointers in C++. It uses an internal table to store these. > ); > > PyRun_SimpleString("print \"... Python finished ...\""); > Py_Finalize(); > } > > X and Y are my classes implemented in C++, connected to Python via Swig Shadow > Classes: > > class X { > > public: > float getNumber() > { > return 12.2; > } > }; > > class Y { > X* pX; > > public: > Y() > { > pX = new X; > } > > ~Y() > { > delete pX; > } > > X* getX() > { > return pX; > } > }; > > The classes and python are compiled statically with CBuilder5.0, Swig1.3a3 (same > problem with swig1.1). > > I tested the application with "CodeGuard", which shows the memory leaks. > For every call in the loop there is an entry like this (I translated it to > English): > > Error. 0x300010 (Thread 0x013B): > resource leak: memory block (0x15422F0) was never released > > memory leak (0x015422F0) [size: 36 Byte] was assigned with malloc > call stack: > 0x0045ED5D(=pythontest.exe:0x01:05DD5D) > G:\Projects\src\fortuna\Python\Objects\stringobject.c#145 > 0x00401EFD(=pythontest.exe:0x01:000EFD) > G:\Projects\src\fortuna\test\xmodule_wrap.c#769 > 0x0040255D(=pythontest.exe:0x01:00155D) > G:\Projects\src\fortuna\test\xmodule_wrap.c#941 > 0x0041BA79(=pythontest.exe:0x01:01AA79) > G:\Projects\src\fortuna\Python\Python\ceval.c#2359 > 0x0041B912(=pythontest.exe:0x01:01A912) > G:\Projects\src\fortuna\Python\Python\ceval.c#2324 > 0x0040EE3E(=pythontest.exe:0x01:00DE3E) > G:\Projects\src\fortuna\Python\Python\bltinmodule.c#12 > > The Code for line 941: > > #define Y_getX(_swigobj) (_swigobj->getX()) > static PyObject *_wrap_Y_getX(PyObject *self, PyObject *args) { > Y *_arg0; > PyObject *_resultobj,*_argo0=0; > X *_result; > self = self; > if(!PyArg_ParseTuple(args,"O:Y_getX",&_argo0)) > return NULL; > if ((SWIG_ConvertPtr(_argo0,(void **) &_arg0,SWIGTYPE_Y_p,1)) == -1) return > NULL; > _result = (X *)Y_getX(_arg0); > /*941*/ _resultobj = SWIG_NewPointerObj((void *) _result, SWIGTYPE_X_p); > return _resultobj; > } > > The Code for line 769: > > SWIGSTATICRUNTIME(PyObject *) > SWIG_NewPointerObj(void *ptr, _swig_type_info *type) { > char result[512]; > PyObject *robj; > if (!ptr) { > Py_INCREF(Py_None); > return Py_None; > } > #ifdef SWIG_COBJECT_TYPES > robj = PyCObject_FromVoidPtrAndDesc((void *) ptr, type->name, NULL); > #else > SWIG_MakePtr(result,ptr,type); > /*769*/ robj = PyString_FromString(result); > #endif > return robj; > } > > Ingo Adler > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: Ingo Adler Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 11:40:42 +0100 This is a multi-part message in MIME format. --------------6D29988B97CCE77010389AE2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > // The Loop > > PyRun_SimpleString( > > "y = Y()\n" > > "for i in range(1000):\n" > > "\tx = y.getX()\n" > > "\tx.getNumber()\n" > > Could be that SWIG doesn't get a chance to cleanup the shadow > object for x and y. Try adding > > del x,y > > as final script line. > > Note that SWIG uses Python strings to represent pointers in > C++. It uses an internal table to store these. > I changed the code to: PyRun_SimpleString( "y = Y()\n" "for i in range(1000):\n" "\tx = y.getX()\n" "\tx.getNumber()\n" "\tdel x\n" ); It doesn't change anything. The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x = y.getX() is memory leak free. Ingo Adler --------------6D29988B97CCE77010389AE2 Content-Type: text/x-vcard; charset=us-ascii; name="ingo.adler.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ingo Adler Content-Disposition: attachment; filename="ingo.adler.vcf" begin:vcard n:Adler;Ingo tel;cell:+41-79-3786792 tel;fax:+41-41-7103244 tel;home:+41-41-7103268 tel;work:+41-41-8111500 x-mozilla-html:FALSE url:www.synacon.ch org:Synacon GmbH adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland version:2.1 email;internet:ingo.adler@synacon.ch title:Dipl.-Inform. fn:Ingo Adler end:vcard --------------6D29988B97CCE77010389AE2-- ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: "M.-A. Lemburg" Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 12:13:13 +0200 Ingo Adler wrote: > > > > // The Loop > > > PyRun_SimpleString( > > > "y = Y()\n" > > > "for i in range(1000):\n" > > > "\tx = y.getX()\n" > > > "\tx.getNumber()\n" > > > > Could be that SWIG doesn't get a chance to cleanup the shadow > > object for x and y. Try adding > > > > del x,y > > > > as final script line. > > > > Note that SWIG uses Python strings to represent pointers in > > C++. It uses an internal table to store these. > > > > I changed the code to: > > PyRun_SimpleString( > "y = Y()\n" > "for i in range(1000):\n" > "\tx = y.getX()\n" > "\tx.getNumber()\n" > "\tdel x\n" > ); > > It doesn't change anything. > > The memory leak only occurs when I call x.getNumber() in the loop. Otherwise x = > y.getX() is memory leak free. Two other possibilities: 1. Python interns the string object used by SWIG to represent the point. It should then free the memory in the Py_Finalize() call. If it doesn't, there's a bug to be found ;-) 2. SWIG has the leak. Try using the alternative method of defining SWIG_COBJECT_TYPES (don't know how this is done -- it seems to be new in SWIG). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: Ingo Adler Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Fri, 14 Jul 2000 12:45:02 +0100 This is a multi-part message in MIME format. --------------82393A6779ADCFC3A2ADE19E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I could reproduce the problem with Developer Studio 6.0. If anyone wants the project to test it - I can provide it. Ingo Adler --------------82393A6779ADCFC3A2ADE19E Content-Type: text/x-vcard; charset=us-ascii; name="ingo.adler.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ingo Adler Content-Disposition: attachment; filename="ingo.adler.vcf" begin:vcard n:Adler;Ingo tel;cell:+41-79-3786792 tel;fax:+41-41-7103244 tel;home:+41-41-7103268 tel;work:+41-41-8111500 x-mozilla-html:FALSE url:www.synacon.ch org:Synacon GmbH adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland version:2.1 email;internet:ingo.adler@synacon.ch title:Dipl.-Inform. fn:Ingo Adler end:vcard --------------82393A6779ADCFC3A2ADE19E-- ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] memory leak in loops (PR#398) Date: Mon, 17 Jul 2000 22:16:54 -0400 > I could reproduce the problem with Developer Studio 6.0. > > If anyone wants the project to test it - I can provide it. If you can repro the problem in just a few lines of C/C++ code but with no SWIG generated code, I would be interested. Otherwise, I suggest you do some more work to narrow the problem down some more; as described, there is still too much work to be done to narrow down the problem to the cause for me to be interested (or anyone else given the feedback to date!) Mark. ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: Ingo Adler Subject: Re: [Python-bugs-list] memory leak in loops (PR#398) Date: Tue, 25 Jul 2000 01:34:22 +0200 This is a multi-part message in MIME format. --------------72A23DA082087CB843E12C92 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mark, I could repro the memory leaks (they seem to be the same) with a much smaller program: int main(int argc, char* argv[]) { Py_SetProgramName("pythontest.exe"); Py_Initialize(); PyRun_SimpleString("print \"... Python started ...\""); PyRun_SimpleString("print \"... Python finished ...\""); Py_Finalize(); return 0; } There seems to be a more general problem, which includes my special problem. Output of Code Guard (translated to English). BoundsChecker shows the same leaks. Ingo Output: Memory Block (0x014EB9B4) [Size: 37 Byte] was assigned with malloc Aufrufhierarchie: 0x0043515A(=pythontest.exe:0x01:03415A) D:\projects\Python\Objects\stringobject.c#95 0x0043A8EB(=pythontest.exe:0x01:0398EB) D:\projects\Python\Python\marshal.c#483 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 0x0043AB88(=pythontest.exe:0x01:039B88) D:\projects\Python\Python\marshal.c#568 0x0043AD37(=pythontest.exe:0x01:039D37) D:\projects\Python\Python\marshal.c#624 0x0042BC54(=pythontest.exe:0x01:02AC54) D:\projects\Python\Python\import.c#575 ------------------------------------------ Error 00078. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E4858) was never freed Memory Block (0x014E4858) [Size: 31 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00425400(=pythontest.exe:0x01:024400) D:\projects\Python\Objects\dictobject.c#1084 0x00433896(=pythontest.exe:0x01:032896) D:\projects\Python\Objects\moduleobject.c#56 0x0042B993(=pythontest.exe:0x01:02A993) D:\projects\Python\Python\import.c#428 0x0043B0C9(=pythontest.exe:0x01:03A0C9) D:\projects\Python\Python\modsupport.c#82 0x0040C68A(=pythontest.exe:0x01:00B68A) D:\projects\Python\Python\bltinmodule.c#2393 ------------------------------------------ Error 00079. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E47D0) was never freed Memory Block (0x014E47D0) [Size: 28 Byte] was assigned with malloc Aufrufhierarchie: 0x00433CB3(=pythontest.exe:0x01:032CB3) D:\projects\Python\Objects\object.c#122 0x00424115(=pythontest.exe:0x01:023115) D:\projects\Python\Objects\dictobject.c#124 0x004367D3(=pythontest.exe:0x01:0357D3) D:\projects\Python\Objects\stringobject.c#1075 0x00425418(=pythontest.exe:0x01:024418) D:\projects\Python\Objects\dictobject.c#1087 0x0043387A(=pythontest.exe:0x01:03287A) D:\projects\Python\Objects\moduleobject.c#54 0x0042B993(=pythontest.exe:0x01:02A993) D:\projects\Python\Python\import.c#428 ------------------------------------------ Error 00080. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E47AC) was never freed Memory Block (0x014E47AC) [Size: 32 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00425400(=pythontest.exe:0x01:024400) D:\projects\Python\Objects\dictobject.c#1084 0x0043387A(=pythontest.exe:0x01:03287A) D:\projects\Python\Objects\moduleobject.c#54 0x0042B993(=pythontest.exe:0x01:02A993) D:\projects\Python\Python\import.c#428 0x0043B0C9(=pythontest.exe:0x01:03A0C9) D:\projects\Python\Python\modsupport.c#82 0x0040C68A(=pythontest.exe:0x01:00B68A) D:\projects\Python\Python\bltinmodule.c#2393 ------------------------------------------ Error 00081. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E46E4) was never freed Memory Block (0x014E46E4) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x004240F7(=pythontest.exe:0x01:0230F7) D:\projects\Python\Objects\dictobject.c#120 0x0043C27B(=pythontest.exe:0x01:03B27B) D:\projects\Python\Python\pythonrun.c#132 0x00402934(=pythontest.exe:0x01:001934) G:\Projects\src\test\pythonmain.cpp#15 0x3257DC12(=CC3250MT.DLL:0x01:07CC12) ------------------------------------------ Error 00082. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x1524000) was never freed Memory Block (0x01524000) [Size: 12288 Byte] was assigned with malloc Aufrufhierarchie: 0x004243A7(=pythontest.exe:0x01:0233A7) D:\projects\Python\Objects\dictobject.c#280 0x004245C4(=pythontest.exe:0x01:0235C4) D:\projects\Python\Objects\dictobject.c#370 0x00436837(=pythontest.exe:0x01:035837) D:\projects\Python\Objects\stringobject.c#1086 0x00415CA9(=pythontest.exe:0x01:014CA9) D:\projects\Python\Python\compile.c#249 0x0043AC12(=pythontest.exe:0x01:039C12) D:\projects\Python\Python\marshal.c#578 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 ------------------------------------------ Error 00083. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFC9C) was never freed Memory Block (0x014EFC9C) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411EE6(=pythontest.exe:0x01:010EE6) D:\projects\Python\Objects\classobject.c#126 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00084. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFC74) was never freed Memory Block (0x014EFC74) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411ED6(=pythontest.exe:0x01:010ED6) D:\projects\Python\Objects\classobject.c#125 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00085. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFC4C) was never freed Memory Block (0x014EFC4C) [Size: 35 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411EC6(=pythontest.exe:0x01:010EC6) D:\projects\Python\Objects\classobject.c#124 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00086. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14F19CC) was never freed Memory Block (0x014F19CC) [Size: 47 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00431E97(=pythontest.exe:0x01:030E97) D:\projects\Python\Objects\listobject.c#309 0x0041137E(=pythontest.exe:0x01:01037E) D:\projects\Python\Python\ceval.c#2512 0x0040F906(=pythontest.exe:0x01:00E906) D:\projects\Python\Python\ceval.c#1503 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 0x0042BAD4(=pythontest.exe:0x01:02AAD4) D:\projects\Python\Python\import.c#485 ------------------------------------------ Error 00087. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14F596C) was never freed Memory Block (0x014F596C) [Size: 32 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x0042CED6(=pythontest.exe:0x01:02BED6) D:\projects\Python\Python\import.c#1513 0x0042CD19(=pythontest.exe:0x01:02BD19) D:\projects\Python\Python\import.c#1441 0x0042CE6A(=pythontest.exe:0x01:02BE6A) D:\projects\Python\Python\import.c#1489 0x00409B32(=pythontest.exe:0x01:008B32) D:\projects\Python\Python\bltinmodule.c#65 ------------------------------------------ Error 00088. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EB870) was never freed Memory Block (0x014EB870) [Size: 32 Byte] was assigned with malloc Aufrufhierarchie: 0x0043515A(=pythontest.exe:0x01:03415A) D:\projects\Python\Objects\stringobject.c#95 0x0043A8EB(=pythontest.exe:0x01:0398EB) D:\projects\Python\Python\marshal.c#483 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 0x0043AB88(=pythontest.exe:0x01:039B88) D:\projects\Python\Python\marshal.c#568 0x0043A9A1(=pythontest.exe:0x01:0399A1) D:\projects\Python\Python\marshal.c#504 0x0043AB76(=pythontest.exe:0x01:039B76) D:\projects\Python\Python\marshal.c#567 ------------------------------------------ Error 00089. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EFBDC) was never freed Memory Block (0x014EFBDC) [Size: 34 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x00411C9E(=pythontest.exe:0x01:010C9E) D:\projects\Python\Objects\classobject.c#58 0x004118FB(=pythontest.exe:0x01:0108FB) D:\projects\Python\Python\ceval.c#2720 0x0040EE08(=pythontest.exe:0x01:00DE08) D:\projects\Python\Python\ceval.c#1167 0x0040D597(=pythontest.exe:0x01:00C597) D:\projects\Python\Python\ceval.c#324 ------------------------------------------ Error 00090. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E74C4) was never freed Memory Block (0x014E74C4) [Size: 988 Byte] was assigned with malloc Aufrufhierarchie: 0x00430B62(=pythontest.exe:0x01:02FB62) D:\projects\Python\Objects\intobject.c#113 0x00430BFD(=pythontest.exe:0x01:02FBFD) D:\projects\Python\Objects\intobject.c#163 0x0040C6FC(=pythontest.exe:0x01:00B6FC) D:\projects\Python\Python\bltinmodule.c#2404 0x0043C29A(=pythontest.exe:0x01:03B29A) D:\projects\Python\Python\pythonrun.c#136 0x00402934(=pythontest.exe:0x01:001934) G:\Projects\src\test\pythonmain.cpp#15 0x3257DC12(=CC3250MT.DLL:0x01:07CC12) ------------------------------------------ Error 00091. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14E96C4) was never freed Memory Block (0x014E96C4) [Size: 174 Byte] was assigned with malloc Aufrufhierarchie: 0x0042B0D9(=pythontest.exe:0x01:02A0D9) D:\projects\Python\PC\getpathp.c#403 0x0042B2D5(=pythontest.exe:0x01:02A2D5) D:\projects\Python\PC\getpathp.c#508 0x0043E40C(=pythontest.exe:0x01:03D40C) D:\projects\Python\Python\sysmodule.c#413 0x0043C2CA(=pythontest.exe:0x01:03B2CA) D:\projects\Python\Python\pythonrun.c#142 0x00402934(=pythontest.exe:0x01:001934) G:\Projects\src\test\pythonmain.cpp#15 0x3257DC12(=CC3250MT.DLL:0x01:07CC12) ------------------------------------------ Error 00092. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x14EF660) was never freed Memory Block (0x014EF660) [Size: 36 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x00425400(=pythontest.exe:0x01:024400) D:\projects\Python\Objects\dictobject.c#1084 0x0042BA54(=pythontest.exe:0x01:02AA54) D:\projects\Python\Python\import.c#466 0x0042BF73(=pythontest.exe:0x01:02AF73) D:\projects\Python\Python\import.c#724 0x0042C876(=pythontest.exe:0x01:02B876) D:\projects\Python\Python\import.c#1202 0x0042D51E(=pythontest.exe:0x01:02C51E) D:\projects\Python\Python\import.c#1755 ------------------------------------------ Error 00093. 0x300010 (Thread 0x012D): Resource-Leak: Memory Block (0x15211C8) was never freed Memory Block (0x015211C8) [Size: 31 Byte] was assigned with malloc Aufrufhierarchie: 0x0043526B(=pythontest.exe:0x01:03426B) D:\projects\Python\Objects\stringobject.c#145 0x0043685E(=pythontest.exe:0x01:03585E) D:\projects\Python\Objects\stringobject.c#1098 0x004129EE(=pythontest.exe:0x01:0119EE) D:\projects\Python\Objects\classobject.c#517 0x004246DD(=pythontest.exe:0x01:0236DD) D:\projects\Python\Objects\dictobject.c#419 0x0042546E(=pythontest.exe:0x01:02446E) D:\projects\Python\Objects\dictobject.c#1103 0x0043DF2E(=pythontest.exe:0x01:03CF2E) D:\projects\Python\Python\sysmodule.c#95 ------------------------------------------ Aufgerufene Funktionen: delete (35 Mal) getchar (1 Mal) fflush (2 Mal) fputs (2 Mal) fwrite (2 Mal) vsprintf (2 Mal) strrchr (14 Mal) fclose (14 Mal) strspn (251 Mal) fread (2021 Mal) _fgetc (40 Mal) fstat (7 Mal) fopen (72 Mal) strncmp (19 Mal) strcmp (423 Mal) stat (21 Mal) strncpy (32 Mal) strchr (125 Mal) sprintf (2 Mal) memcmp (1349 Mal) memset (133 Mal) strcpy (834 Mal) strlen (784 Mal) SysFreeMem (87 Mal) SysGetMem (87 Mal) realloc (88 Mal) memcpy (837 Mal) delete[] (2 Mal) free (4936 Mal) new[] (14 Mal) new (40 Mal) calloc (5 Mal) malloc (4946 Mal) Verwendete Resource-Arten: Datei-Stream (14 Allocs, 5 max) Datei-Handle (14 Allocs, 5 max) Objekt-Array (14 Allocs, 13 max) Objekt (40 Allocs, 28 max) Memory Block (5039 Allocs, 2448 max) Verwendete Module: 00400000 07/25/2000 01:06:08 G:\Projects\src\bin\pythontest.exe 0CD00000 02/03/2000 06:00:00 g:\programme\borland\cbuilder5\bin\CG32.DLL 201A0000 02/22/2000 05:20:00 C:\WINNT.45\TRAYHOOK.dll 32500000 02/03/2000 06:00:00 G:\Projects\src\bin\CC3250MT.DLL 40000000 02/03/2000 05:01:00 C:\WINNT.45\System32\VCL50.BPL 41000000 02/03/2000 06:00:00 G:\Projects\src\bin\BORLNDMM.DLL 52180000 08/09/1996 00:00:00 C:\WINNT.45\system32\version.dll 61220000 12/07/1999 16:03:46 G:\Programme\Microsoft Hardware\Mouse\MSH_ZWF.dll 65340000 02/18/2000 16:16:02 C:\WINNT.45\system32\oleaut32.dll 70970000 05/09/1998 13:57:06 C:\WINNT.45\system32\SHELL32.dll 70BD0000 03/18/1999 00:00:00 C:\WINNT.45\system32\SHLWAPI.dll 71190000 07/22/1999 21:09:08 C:\WINNT.45\system32\MSIDLE.DLL 71590000 03/18/1999 00:00:00 C:\WINNT.45\system32\COMCTL32.dll 73060000 05/13/1999 12:05:00 C:\WINNT.45\System32\winspool.drv 77660000 05/13/1999 12:05:00 C:\WINNT.45\System32\MSWSOCK.dll 77666C35 05/13/1999 12:05:00 C:\WINNT.45\system32\wsock32.dll 77690000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2HELP.dll 776A0000 05/13/1999 12:05:00 C:\WINNT.45\system32\WS2_32.dll 77710000 05/13/1999 12:05:00 C:\WINNT.45\system32\mpr.dll 77920000 05/13/1999 12:05:00 C:\WINNT.45\System32\oledlg.dll 779B0000 08/09/1996 00:00:00 C:\WINNT.45\system32\LZ32.dll 77B80000 05/13/1999 12:05:00 C:\WINNT.45\system32\ole32.dll 77D80000 05/13/1999 12:05:00 C:\WINNT.45\system32\comdlg32.dll 77DC0000 05/13/1999 12:05:00 C:\WINNT.45\system32\ADVAPI32.dll 77E10000 05/13/1999 12:05:00 C:\WINNT.45\system32\RPCRT4.dll 77E70000 05/13/1999 12:05:00 C:\WINNT.45\system32\user32.dll 77ED0000 05/13/1999 12:05:00 C:\WINNT.45\system32\GDI32.dll 77F00000 05/13/1999 12:05:00 C:\WINNT.45\system32\kernel32.dll 77F70000 05/13/1999 12:05:00 C:\WINNT.45\System32\ntdll.dll 78000000 12/07/1999 05:00:00 C:\WINNT.45\system32\MSVCRT.dll ========================================== Mark Hammond wrote: > > I could reproduce the problem with Developer Studio 6.0. > > > > If anyone wants the project to test it - I can provide it. > > If you can repro the problem in just a few lines of C/C++ code but with no > SWIG generated code, I would be interested. Otherwise, I suggest you do > some more work to narrow the problem down some more; as described, there is > still too much work to be done to narrow down the problem to the cause for > me to be interested (or anyone else given the feedback to date!) > > Mark. --------------72A23DA082087CB843E12C92 Content-Type: text/x-vcard; charset=us-ascii; name="ingo.adler.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ingo Adler Content-Disposition: attachment; filename="ingo.adler.vcf" begin:vcard n:Adler;Ingo tel;fax:+41-41-7103244 tel;work:+41-41-8111500 x-mozilla-html:FALSE org:Synacon GmbH adr:;;Rubiswilstrasse 7;Ibach;SZ;6438;Schwitzerland version:2.1 email;internet:ingo.adler@synacon.ch fn:Ingo Adler end:vcard --------------72A23DA082087CB843E12C92-- ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: Actually, it's hard to say whether this is worth fixing... Could it be a SWIG problem? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110681&group_id=5470 From noreply@sourceforge.net Fri Aug 4 14:58:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 06:58:50 -0700 Subject: [Python-bugs-list] [Bug #110704] IDLE (PR#400) Message-ID: <200008041358.GAA30113@delerium.i.sourceforge.net> Bug #110704, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: IDLE (PR#400) Details: Jitterbug-Id: 400 Submitted-By: crislipm@earthlink.net Date: Sun, 16 Jul 2000 20:40:24 -0400 (EDT) Version: 1.5.2 OS: Linuxppc, Suse dist more for curiosity/FYI Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an ibook (version 2). IDLE causes the keyboard to stop working (I am not certain which, if any action, causes this, but it is reproducable) and the problem continues when I warm boot back to the MAC OS. Have to do a cold boot to get keyboard to respond again. ==================================================================== Audit trail: Mon Jul 24 18:30:07 2000 jeremy changed notes Mon Jul 24 18:30:07 2000 jeremy moved from incoming to platformbug For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110704&group_id=5470 From noreply@sourceforge.net Fri Aug 4 15:00:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 4 Aug 2000 07:00:44 -0700 Subject: [Python-bugs-list] [Bug #110710] Segmentation fault on range (PR#71) Message-ID: <200008041400.HAA30231@delerium.i.sourceforge.net> Bug #110710, was updated on 2000-Jul-31 14:30 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 4 Summary: Segmentation fault on range (PR#71) Details: Jitterbug-Id: 71 Submitted-By: mz@pdm.pvt.net Date: Mon, 6 Sep 1999 06:45:45 -0400 (EDT) Version: 1.5.2 OS: Debian GNU/Linux 2.1 When I start python and try to evaluate `range(1000000000)', I receive segmentation fault: $ python Python 1.5.2 (#0, May 4 1999, 14:45:33) [GCC 2.7.2.3] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> range(1000000000) Segmentation fault This can also be reproduced with Python 1.5.1 from the Debian 2.1 i386 distribution. ==================================================================== Audit trail: Tue Sep 07 11:13:29 1999 guido changed notes Tue Sep 07 11:13:29 1999 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-04 07:00 By: jhylton Comment: I can't reproduce this bug on 1.5.2 or current CVS. In both cases, I get a MemoryError. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110710&group_id=5470 From noreply@sourceforge.net Sat Aug 5 11:57:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 5 Aug 2000 03:57:47 -0700 Subject: [Python-bugs-list] [Bug #110713] strptime buffer overflow (PR#95) Message-ID: <200008051057.DAA03278@delerium.i.sourceforge.net> Bug #110713, was updated on 2000-Jul-31 14:30 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: Works For Me Bug Group: Platform-specific Priority: 7 Summary: strptime buffer overflow (PR#95) Details: Jitterbug-Id: 95 Submitted-By: bridge@gsnet.com Date: Tue, 5 Oct 1999 12:45:12 -0400 (EDT) Version: 1.5.2 OS: RedHat 5.2 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) ==================================================================== Audit trail: Wed Oct 06 11:12:55 1999 guido changed notes Wed Oct 06 11:12:55 1999 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-05 03:57 By: nowonder Comment: I cannot test this as I do not have RedHat 5.2. It works for me on SuSE Linux 6.4 both with 1.5.2 and the current CVS version. Somebody with a RedHat 5.2 system should check this out. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110713&group_id=5470 From noreply@sourceforge.net Sat Aug 5 14:03:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 5 Aug 2000 06:03:57 -0700 Subject: [Python-bugs-list] [Bug #110819] test suite incomplete (PR#1) Message-ID: <200008051303.GAA14291@bush.i.sourceforge.net> Bug #110819, was updated on 2000-Aug-01 14:09 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: test suite incomplete (PR#1) Details: Jitterbug-Id: 1 Submitted-By: guido@python.org Date: Mon, 3 May 1999 17:31:27 -0400 (EDT) Version: any OS: any Subject says it all. Not everything is tested. ==================================================================== Audit trail: Mon May 03 18:01:53 1999 guido sent reply 1 Mon Jul 12 15:33:07 1999 guido moved from incoming to request Mon Jul 12 19:09:04 1999 guido changed notes Follow-Ups: Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: test suite incomplete (PR#1) Date: Mon May 3 18:01:53 1999 I know, I know... ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: Of course, it's not likely that this will ever by completely resolved... :-) ------------------------------------------------------- Date: 2000-Aug-01 17:45 By: jhylton Comment: Thought you'd like to have this one assigned to you, Skip . ------------------------------------------------------- Date: 2000-Aug-05 06:03 By: montanaro Comment: as if i didn't have enough to do... ;-) maybe this is a good excuse to look at pyUnit. More tests might get written with a more easily used testing framework. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110819&group_id=5470 From noreply@sourceforge.net Sat Aug 5 19:45:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 5 Aug 2000 11:45:12 -0700 Subject: [Python-bugs-list] [Bug #110687] mailbox module's maildir class broken? (PR#414) Message-ID: <200008051845.LAA24456@bush.i.sourceforge.net> Bug #110687, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 3 Summary: mailbox module's maildir class broken? (PR#414) Details: Jitterbug-Id: 414 Submitted-By: arb@anand.org Date: Wed, 26 Jul 2000 12:23:32 -0400 (EDT) Version: 1.5.2 OS: i386-Redhat-linux 6.2 I'm using the "mailbox" module that comes with python. I'm trying to use the maildir class in there, but I think it's not following the maildir protocol properly. The maildir protocol specifies that in a Maildir, a message file can have any name that is unique, as long as it doesn't begin with a period. However, the maildir class looks for valid message filenames, by checking to see if the filename has more than 1 period in it, ie. consists of 3 or more sections separated by periods. Typically, this is the sort of name one finds in a Maildir, because the Maildir protocol page describes one simple way of creating a unique filename, ie. by using the timestamp, pid of the writer, and the hostname. However, when I insert messages into a maildir which don't follow that system of generating unique filenames, the maildir class of the module doesn't see them. Additioanlly, it _does_ see message files which begin with a period, eg. .12345678.1234.hostname. This is also a violation of the maildir protocol. I believe that a maildir reader should simply look at all files in a maildir, no matter what the name, except for those that begin with a period. ==================================================================== Audit trail: Wed Jul 26 18:15:33 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] mailbox module's maildir class broken? (PR#414) Date: Wed, 26 Jul 2000 17:31:29 -0500 > I'm using the "mailbox" module that comes with python. I'm trying to > use the maildir class in there, but I think it's not following the > maildir protocol properly. The maildir protocol specifies that in a > Maildir, a message file can have any name that is unique, as long as > it doesn't begin with a period. However, the maildir class looks > for valid message filenames, by checking to see if the filename has > more than 1 period in it, ie. consists of 3 or more sections > separated by periods. Typically, this is the sort of name one finds > in a Maildir, because the Maildir protocol page describes one simple > way of creating a unique filename, ie. by using the timestamp, pid > of the writer, and the hostname. However, when I insert messages > into a maildir which don't follow that system of generating unique > filenames, the maildir class of the module doesn't see > them. Additioanlly, it _does_ see message files which begin with a > period, eg. .12345678.1234.hostname. This is also a violation of the > maildir protocol. I believe that a maildir reader should simply look > at all files in a maildir, no matter what the name, except for those > that begin with a period. You're probably right. I've never used that code, and according to the logs it was contributed to Mike Meyer (no email known). Perhaps you would be willing to create a patch? See http://www.python.org/patches/ for submission guidelines. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) ------------------------------------------------------- Date: 2000-Aug-05 11:45 By: twouters Comment: This bug is still present. Fred is/was working on the 'mailbox' module, but I do not know whether he'll fix this, too. If not, I'll do it, it's not that big a chance. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110687&group_id=5470 From noreply@sourceforge.net Sat Aug 5 19:47:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 5 Aug 2000 11:47:23 -0700 Subject: [Python-bugs-list] [Bug #110830] Syntax (PR#177) Message-ID: <200008051847.LAA24580@bush.i.sourceforge.net> Bug #110830, was updated on 2000-Aug-01 14:12 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: Later Bug Group: Feature Request Priority: 1 Summary: Syntax (PR#177) Details: Jitterbug-Id: 177 Submitted-By: simonb@logical.co.za Date: Tue, 11 Jan 2000 05:17:37 -0500 (EST) Version: 1-5-2 OS: NT 4.0 Hi there I don't know if this is a bug, or is intentional behaviour for a specific reason. The following code produces a syntax error about the continue not being within a looping structure rather than a prefectly silly infinite loop... while 1: try: continue except: pass where the following works as one would expect... while 1: try: raise 1 except: continue I figure that there is more likely a sane reason for this behaviour than being a bug, but I am curious. Thanks Simon ==================================================================== Audit trail: Wed Jan 12 18:11:45 2000 guido changed notes Wed Jan 12 18:11:45 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:12 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] Syntax (PR#177) Date: Tue, 11 Jan 2000 12:10:17 -0500 [Simon Barratt, putting "continue" in a "try" block] > I don't know if this is a bug, or is intentional behaviour > for a specific reason. Actually, it's a bit of both . See the Language Reference Manual's section on the "continue" statement, particularly the footnote: The restriction on occurring in the try clause is implementer's laziness and will eventually be lifted. It's been this way (and documented) forever; it's simply hard to implement given the current structure of the interpreter loop. Rest assured there's nothing *conceptually* wrong with putting continue in a try! It's simply an implementation restriction; the error msg should probably make that clearer. IIRC, JPython doesn't have this restriction. "Someday" it will get repaired in CPython too. ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: It's a zero-priority bug (i.e. not likely to be fixed). ------------------------------------------------------- Date: 2000-Aug-03 13:00 By: twouters Comment: Like the bot said, low priority 'to be fixed' bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110830&group_id=5470 From noreply@sourceforge.net Sat Aug 5 19:50:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 5 Aug 2000 11:50:43 -0700 Subject: [Python-bugs-list] [Bug #110924] exec unicodeobject doesn't work Message-ID: <200008051850.LAA24619@bush.i.sourceforge.net> Bug #110924, was updated on 2000-Aug-02 08:17 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: exec unicodeobject doesn't work Details: exec u"print 42" doesn't work. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470 From noreply@sourceforge.net Sat Aug 5 19:54:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 5 Aug 2000 11:54:56 -0700 Subject: [Python-bugs-list] [Bug #110623] build on NeXTStep (PR#240) Message-ID: <200008051854.LAA24756@bush.i.sourceforge.net> Bug #110623, was updated on 2000-Jul-31 14:07 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: build on NeXTStep (PR#240) Details: Jitterbug-Id: 240 Submitted-By: kragen@pobox.com (Kragen Sitaker) Date: Fri, 17 Mar 2000 16:09:19 -0500 (EST) Version: None OS: None I'm building Python on NeXTStep; I've encountered three minor problems. - importdl.c by default on NeXTStep allows linking with Objective-C modules, which is cool. Unfortunately, properly supporting this requires adding -ObjC to the cc command line in the Makefile. - posixmodule.c doesn't #include anything that declares fsync() and doesn't declare it itself, but tries to reference it. Adding a declaration of fsync() fixes the problem. - test_strftime and test_time fail. test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' I suspect this may be a platform bug. Here's some of the output, which is 696 lines in full: strftime test for Fri Mar 17 12:53:20 2000 Strftime test, platform: next3_3, Python version: 1.5.2 Conflict for %j (julian day (001-366)): Expected 077, but got 076 Conflict for nonstandard '%c' format (near-asctime() format): Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20 2000 Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S): Expected 03/17/00, but got Fri Mar 17 2000 Does not appear to support '%Z' format (time zone name) Conflict for nonstandard '%D' format (mm/dd/yy): Expected 03/17/00, but got ? Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)): Expected 17, but got ? Conflict for nonstandard '%h' format (abbreviated month name): Expected Mar, but got ? Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)): Expected 12, but got ? Conflict for nonstandard '%n' format (newline character): Expected , but got ? Conflict for nonstandard '%r' format (%I:%M:%S %p): Expected 12:53:20 PM, but got ? Conflict for nonstandard '%R' format (%H:%M): Expected 12:53, but got ? Conflict for nonstandard '%s' format (seconds since the Epoch in UCT): Expected 953326400, but got ? Conflict for nonstandard '%t' format (tab character): Expected , but got ? Conflict for nonstandard '%T' format (%H:%M:%S): Expected 12:53:20, but got ? Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth): Expected 000, but got ?y Conflict for %j (julian day (001-366)): Expected 327, but got 326 Conflict for %W (week number of the year (Mon 1st)): Expected 46, but got 47 Conflict for %j (julian day (001-366)): Expected 328, but got 327 Conflict for %j (julian day (001-366)): Expected 329, but got 328 Conflict for %j (julian day (001-366)): Expected 330, but got 329 test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: '' (and that was all of the output from test_time. Presumably this is related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports 'Command not found'. I'm not trying to build a very sophisticated environment --- just the defaults. -- Kragen Sitaker The Internet stock bubble didn't burst on 1999-11-08. Hurrah! The power didn't go out on 2000-01-01 either. :) ==================================================================== Audit trail: Mon Apr 03 18:40:11 2000 guido changed notes Mon Apr 03 18:40:11 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:07 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Fri, 24 Mar 2000 10:05:14 -0500 > I'm building Python on NeXTStep; I've encountered three minor problems. > > - importdl.c by default on NeXTStep allows linking with Objective-C > modules, which is cool. Unfortunately, properly supporting this > requires adding -ObjC to the cc command line in the Makefile. > - posixmodule.c doesn't #include anything that declares fsync() and > doesn't declare it itself, but tries to reference it. Adding a > declaration of fsync() fixes the problem. > - test_strftime and test_time fail. > test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' > I suspect this may be a platform bug. Here's some of the output, > which is 696 lines in full: [...] > (and that was all of the output from test_time. Presumably this is > related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) > > I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports > 'Command not found'. > > I'm not trying to build a very sophisticated environment --- just the > defaults. Kragen, Can you send us some patches? We don't have a NextStep system around to test any of this, and your description of the problem doesn't help me to create fixes that will certainly work for you. There's probably not much you can do about the strftime problem -- just don't use time.strftime()! :-) Please read python.org/patches for info on how to submit patches. Thanks for contributing! --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:07 By: none Comment: From: kragen@pobox.com (Kragen Sitaker) Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Tue, 28 Mar 2000 12:46:18 -0500 (EST) Guido writes: > [Kragen wrote:] > > I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' > > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports > > 'Command not found'. It's NeXTStep 3.3. > Can you send us some patches? We don't have a NextStep system around > to test any of this, and your description of the problem doesn't help > me to create fixes that will certainly work for you. I can send a patch for importdl.c; the right thing to do for this would be to modify the Makefile to change the flags passed to the compiler to include -ObjC, but I don't know how to do that. My solution was to change a #define in the source to turn off the ability to import Objective-C modules, which is obviously far from optimal --- thus my failure to include a patch for this in the first email. In posixmodule.c, which needs fsync() declared, I'm not sure where to declare it. I can certainly supply a patch that works for NeXTStep 3.3, but I don't understand the rat's-nest of #ifdefs there well enough to be sure it won't break compilation on some other platform, or even another version of NeXTStep --- thus my failure to include a patch for this in the first email. So I can send patches for both of these, but I am not sure if I should. > Please read python.org/patches for info on how to submit patches. Thanks. -- Kragen Sitaker The Internet stock bubble didn't burst on 1999-11-08. Hurrah! The power didn't go out on 2000-01-01 either. :) ------------------------------------------------------- Date: 2000-Jul-31 14:07 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Tue, 28 Mar 2000 14:41:28 -0500 > It's NeXTStep 3.3. > > > Can you send us some patches? We don't have a NextStep system around > > to test any of this, and your description of the problem doesn't help > > me to create fixes that will certainly work for you. > > I can send a patch for importdl.c; the right thing to do for this would > be to modify the Makefile to change the flags passed to the compiler to > include -ObjC, but I don't know how to do that. My solution was to > change a #define in the source to turn off the ability to import > Objective-C modules, which is obviously far from optimal --- thus my > failure to include a patch for this in the first email. > > In posixmodule.c, which needs fsync() declared, I'm not sure where to > declare it. I can certainly supply a patch that works for NeXTStep > 3.3, but I don't understand the rat's-nest of #ifdefs there well enough > to be sure it won't break compilation on some other platform, or even > another version of NeXTStep --- thus my failure to include a patch for > this in the first email. > > So I can send patches for both of these, but I am not sure if I should. Maybe we should just drop it? I don't think NextStep 3.3 has much future or even much current use, does it? it's only supported for historic reasons. If you get it to work, fine -- but I don't think the general public would benefit much from adding NS 3.3 support... Or am I wrong? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110623&group_id=5470 From noreply@sourceforge.net Sun Aug 6 11:12:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 03:12:53 -0700 Subject: [Python-bugs-list] [Bug #110619] urllib.py fails with username/password proxies (PR#221) Message-ID: <200008061012.DAA10460@delerium.i.sourceforge.net> Bug #110619, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urllib.py fails with username/password proxies (PR#221) Details: Jitterbug-Id: 221 Submitted-By: tarka@zip.com.au Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST) Version: 1.5.2 OS: Irix urllib.py fails to handle proxies with user and password information included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234 The following example ... import os, urllib os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234" f = urllib.urlopen('http://www.python.org') data = f.read() print data fails with the following errors : Traceback (innermost last): File "url.py", line 3, in ? f = urllib.urlopen('http://www.python.org') File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen return _urlopener.open(url) File "/var/share//lib/python1.5/urllib.py", line 157, in open return getattr(self, name)(url) File "/var/share//lib/python1.5/urllib.py", line 253, in open_http h = httplib.HTTP(host) File "/var/share//lib/python1.5/httplib.py", line 51, in __init__ if host: self.connect(host, port) File "/var/share//lib/python1.5/httplib.py", line 75, in connect raise socket.error, "nonnumeric port" IOError: [Errno socket error] nonnumeric port ==================================================================== Audit trail: Mon May 22 17:35:04 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110619&group_id=5470 From noreply@sourceforge.net Sun Aug 6 12:57:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 04:57:04 -0700 Subject: [Python-bugs-list] [Bug #110641] KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Message-ID: <200008061157.EAA23277@bush.i.sourceforge.net> Bug #110641, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Details: Jitterbug-Id: 309 Submitted-By: skip@mojam.com Date: Fri, 28 Apr 2000 17:00:40 -0400 (EDT) Version: 1.5.2, 1.6a2 OS: Linux If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the interpreter exits instead of returning you to the top-level prompt. % python Python 1.5.2+ (#12, Feb 17 2000, 14:52:05) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... % PYTHONSTARTUP= ./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... When run under gdb's control, you can see what's happening: % gdb ./python GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... (gdb) set env PYTHONSTARTUP "" (gdb) run Starting program: /home/beluga/skip/src/python/dist/src/./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... Program received signal SIGINT, Interrupt. 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) bt #0 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) c Continuing. File "", line 2 ^ SyntaxError: invalid syntax >>> It appears that SIGINT isn't handled properly when awaiting console input in certain circumstances. If you can entice the program to continue, things work okay. I don't know interrupt handling from a hole in the ground or I'd investigate further. It is quite annoying, especially considering that Python's input history isn't continuous across sessions... Skip ==================================================================== Audit trail: Mon May 22 17:23:42 2000 guido changed notes Mon May 22 17:23:42 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:40 By: twouters Comment: This seems to be platform specific: On Linux, up-to-date CVS compile, this is reproducible. On BSDI 4.1, however, with an almost-up-to-date CVS compile, ^C doesn't exit the interpreter. ------------------------------------------------------- Date: 2000-Aug-06 04:57 By: twouters Comment: Oh, and it's also definately readline-related. (without readline compiled in, the bug doesn't get triggered, in any case.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110641&group_id=5470 From jerry@quotepool.com Sun Aug 6 15:13:39 2000 From: jerry@quotepool.com (jerry@quotepool.com) Date: Sun, 6 Aug 2000 10:13:39 -0400 (EDT) Subject: [Python-bugs-list] Will you choose the RED or BLUE pill? mfmhl (PR#426) Message-ID: <20000806141339.1D1D31D03B@dinsdale.python.org>

93% WHO RESPOND TO MY AD DON'T MAKE THE CUT!
(Only highly motivated people should call)

I'm dead serious! Now let me tell you why...

Most people don't have drive! They sit around waiting for something to happen.
They see that other people have nice homes, new cars, and MONEY, but why can't they?
They basically feel sorry for themselves, and I can't help these people!

Another reason people are not qualified...

They are skeptical. BUT, the truth is, they are skeptical of themselves!
They don't have the courage to break their routine.
They are comfortable with their set hours, their set pay, and their set future.
I was not comfortable with someone controlling my future,
and I'm not comfortable working with people who are!

STOP
If you are anything like the above, we won't be able to work together!

WHAT DO THE 7% WHO DO MAKE THE CUT DISCOVER?!

People I select through an "interview like" process are forever changed!
They are opened to a world around them that they didn't know existed.
In fact, it's a world that has existed around them their whole lives,
but was purposely hidden from them!


How would you like to...

- Drastically reduce personal, business and capital gains taxes?
- Protect all assets from any form of seizure, liens, or judgments?
- Create a six figure income every 4 months?

How about...

Restoring and preserving complete personal and financial privacy?
Amassing personal wealth, multiplying it and protecting it?
Realizing a 3 to 6 times greater return on your money?
Legally making yourself and your assets completely judgment-proof,
lien-proof, divorce-proof, attorney-proof, IRS-proof?
I could go on...

TAKE A SERIOUS LOOK AT YOUR LIFE

Do you think you are paid what you are worth?
Will you be set to retire in the next few years?
Do you control the course of your day? ...your life?

The fact is we have many people in our enterprise that earn over 50K per month
from the privacy of their own homes, and are retiring in 2 to 3 years (wealthy)
and have total freedom - both personal and financial!

Many have been conditioned to believe it must be illegal, immoral or unethical
to ever earn any real profits from our efforts.

The sad truth is, it's been designed that way by the ultra-rich
and ultra-powerful since before any of us were born!

Who am I?

I'm a BIG thinker, a BIG dreamer, and I believe that I deserve the best that life has to offer.
I answered an ad much like the one you are reading now,
and was eager to hear what it was about.

I knew that I couldn't invest only a few bucks and spend an hour or two
per week to achieve the results I was looking for. I found the right information
and now I control my own destiny!

If you are interested in radically changing your thoughts and your financial future,
I invite you to call TOLL FREE:

1 800 707 4817

My name is Krystina, and I look forward to working with some of you!

* REMEMBER *

I can't do it for you, but I can show you exactly how I do it.
It's as simple as that!

From noreply@sourceforge.net Sun Aug 6 17:39:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 09:39:44 -0700 Subject: [Python-bugs-list] [Bug #110693] 3 failed tests after install (PR#119) Message-ID: <200008061639.JAA31406@bush.i.sourceforge.net> Bug #110693, was updated on 2000-Jul-31 14:28 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: Wont Fix Bug Group: Platform-specific Priority: 5 Summary: 3 failed tests after install (PR#119) Details: Jitterbug-Id: 119 Submitted-By: jsb@brodkey.com Date: Tue, 26 Oct 1999 21:37:22 -0400 (EDT) Version: 1.52 OS: Mandrake 6.1 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 ==================================================================== Audit trail: Thu Oct 28 18:55:27 1999 guido changed notes Thu Oct 28 18:55:27 1999 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-01 14:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] 3 failed tests after install (PR#119) Date: Tue, 26 Oct 1999 22:34:23 -0400 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/) ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] 3 failed tests after install (PR#119) Date: Wed, 27 Oct 1999 00:53:49 -0400 > 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. ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] 3 failed tests after install (PR#119) Date: Wed, 27 Oct 1999 23:22:38 -0400 [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. ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: This is caused by an optimizer bug (maybe for a particular CPU). ------------------------------------------------------- Date: 2000-Aug-06 09:39 By: twouters Comment: Compiler optimizer bugs, probably fixed in recent Mandrake (because they stopped using pgcc, IIRC.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110693&group_id=5470 From noreply@sourceforge.net Sun Aug 6 17:42:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 09:42:24 -0700 Subject: [Python-bugs-list] [Bug #110700] strftime crashes with invalid args (PR#183) Message-ID: <200008061642.JAA31528@bush.i.sourceforge.net> Bug #110700, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: Wont Fix Bug Group: Platform-specific Priority: 5 Summary: strftime crashes with invalid args (PR#183) Details: Jitterbug-Id: 183 Submitted-By: calvin@cs.uni-sb.de Date: Thu, 13 Jan 2000 11:00:38 -0500 (EST) Version: 1.5.2 OS: Linux (Debian slink) test.py: import time # crash it by swapping year and month argument print time.strftime("%d.%m.%Y %H:%M:%S", (1,2000, 1, 0, 0, 0, 0, 1, 0)) python test.py Segmentation fault Well there were similar crashes with time.strptime calls. I think this is a platform bug with the C function strftime, but I did not test this in a C program. ==================================================================== Audit trail: Thu Jan 13 11:04:15 2000 guido changed notes Thu Jan 13 11:04:16 2000 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] strftime crashes with invalid args (PR#183) Date: Thu, 13 Jan 2000 11:03:50 -0500 > Full_Name: Bastian Kleineidam > Version: 1.5.2 > OS: Linux (Debian slink) > Submission from: www-proxy.rz.uni-sb.de (134.96.7.81) > > > test.py: > import time > # crash it by swapping year and month argument > print time.strftime("%d.%m.%Y %H:%M:%S", (1,2000, 1, 0, 0, 0, 0, 1, 0)) > > python test.py > Segmentation fault > > Well there were similar crashes with time.strptime calls. I think this > is a platform bug with the C function strftime, but I did not test this > in a C program. Yes, this is a platform bug. Please report it to the C library folks (sorry, I can't do that for you). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: From: Bastian Kleineidam Subject: Re: [Python-bugs-list] strftime crashes with invalid args (PR#183) Date: Thu, 13 Jan 2000 18:37:14 +0100 (CET) [snip bug report] :) Yes, this is a platform bug. Please report it to the C library folks :) (sorry, I can't do that for you). Ok, did it. So the safe side is to check the arguments before calling time.strftime() Bastian Kleineidam ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: From: Bastian Kleineidam Subject: Re: [Python-bugs-list] strftime crashes with invalid args (PR#183) Date: Thu, 13 Jan 2000 19:39:52 +0100 (CET) :) Yes, this is a platform bug. Please report it to the C library folks :) (sorry, I can't do that for you). I got answer from Andreas Jaeger that this bug is fixed with the current glibc version 2.1.2. Bastian Kleineidam ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: The Linux C library code has a long way to go... ------------------------------------------------------- Date: 2000-Aug-06 09:42 By: twouters Comment: Caused by a (by now fixed) bug in GNU libc, not one in Python, therefor closed the bug report. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110700&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:03:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:03:43 -0700 Subject: [Python-bugs-list] [Bug #110820] Jonathan Craft: Possible to-do addition (PR#116) Message-ID: <200008061703.KAA32196@bush.i.sourceforge.net> Bug #110820, was updated on 2000-Aug-01 14:10 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: Jonathan Craft: Possible to-do addition (PR#116) Details: Jitterbug-Id: 116 Submitted-By: Guido van Rossum Date: Mon, 25 Oct 1999 10:38:58 -0400 Version: None OS: None 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 ==================================================================== Audit trail: Mon Oct 25 15:13:11 1999 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-06 10:03 By: twouters Comment: I believe several people are working on something like this (or at least said they were... they might have quit in despair :-) I'm not sure if this belongs on the Python buglist, though. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110820&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:05:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:05:59 -0700 Subject: [Python-bugs-list] [Bug #110629] Tkinter Image names may be reused (PR#28) Message-ID: <200008061705.KAA32229@bush.i.sourceforge.net> Bug #110629, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Tkinter Image names may be reused (PR#28) Details: Jitterbug-Id: 28 Submitted-By: guido@python.org Date: Wed, 14 Jul 1999 14:00:14 -0400 (EDT) Version: 1.5.2b OS: Mark Lutz wrote me: (BTW, this will probably never surface again (I'm stressing the image object a bit), but I think there's a problem with using the id() of an image as its name. I ran into a situation where an image was drawn in the wrong place, because a newly allocated image object had the same id() as one very recently reclaimed. It's very obscure, will only happen if you have > 1 canvas in a process and happen to be creating and deleting images very quickly, and is too complex for me to describe further at the moment ;-). I worked around it by first generating image names from a simple counter, and then prebuilding all images up front.) ==================================================================== Audit trail: Wed Jul 14 14:00:28 1999 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110629&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:11:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:11:17 -0700 Subject: [Python-bugs-list] [Bug #110822] TCL_LIBRARY variable for win32 (PR#130) Message-ID: <200008061711.KAA32386@bush.i.sourceforge.net> Bug #110822, was updated on 2000-Aug-01 14:10 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Feature Request Priority: 4 Summary: TCL_LIBRARY variable for win32 (PR#130) Details: Jitterbug-Id: 130 Submitted-By: grant.griffin@alliedsignal.com Date: Mon, 15 Nov 1999 15:26:44 -0500 (EST) Version: 1.5.2 OS: Windows NT 4.0 I would like to suggest that the "TCL_LIBRARY" variable be automatically set by the Win32 installer program. Currently, this is a manual process. It can be frustrating for the user because when he tries to run a Tkinter program, it says "cannot find tcl80.dll...". (I was able to figure out the solution here only by digging through comp.lang.python in Deja.) Therefore, I recommend the installer be changed as follows: 1) Do TCL installation before Python, not after. 2) Somehow figure out what the value of TCL_LIBRARY should be as a function of the directory that the user had installed TCL in. 3) Automatically write the proper value of TCL_LIBRARY into the Windows registry. Alternatively, you could just add a prompt like "In order to use TCL with Python, you must set the 'TCL_LIBRARY' environment variable to point to the directory where tcl80.dll is installed." Anyway, thanks, guys--keep up the GREAT work! -Grant ==================================================================== Audit trail: Tue Nov 16 13:58:27 1999 guido changed notes Tue Nov 16 13:58:27 1999 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] TCL_LIBRARY variable for win32 (PR#130) Date: Mon, 15 Nov 1999 15:35:20 -0500 > I would like to suggest that the "TCL_LIBRARY" variable be automatically set by > the Win32 installer program. Currently, this is a manual process. It can be > frustrating for the user because when he tries to run a Tkinter program, it says > "cannot find tcl80.dll...". (I was able to figure out the solution here only by > digging through comp.lang.python in Deja.) > > Therefore, I recommend the installer be changed as follows: > > 1) Do TCL installation before Python, not after. > 2) Somehow figure out what the value of TCL_LIBRARY should be as a function of > the directory that the user had installed TCL in. > 3) Automatically write the proper value of TCL_LIBRARY into the Windows > registry. > > Alternatively, you could just add a prompt like "In order to use TCL with > Python, you must set the 'TCL_LIBRARY' environment variable to point to the > directory where tcl80.dll is installed." > > Anyway, thanks, guys--keep up the GREAT work! Thanks for the suggestion. The problem is that on Windows 95/98, the environment is not kept in the registry! Editing autoexec.bat has been suggested but is too error-prone. But we will definitely revisit this problem again with the next release (not due until late 2000); the best solution we can think of is to integrate the Tcl files in the Python installation instead of running the Tcl installer; this way we can be sure that Tcl is always in the same directory as Python. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: We will try to fgix this for Python 1.6. ------------------------------------------------------- Date: 2000-Aug-06 10:11 By: twouters Comment: Partly (or completely ?) resolved by including Tcl/Tk in the Python Installer for Windows. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110822&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:17:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:17:54 -0700 Subject: [Python-bugs-list] [Bug #110637] ihooks on windows and pythoncom (PR#294) Message-ID: <200008061717.KAA32670@bush.i.sourceforge.net> Bug #110637, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: ihooks on windows and pythoncom (PR#294) Details: Jitterbug-Id: 294 Submitted-By: mak@mikroplan.com.pl Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT) Version: cvs OS: windows Hi, Python module ihooks is not so compatible with builtin imp while importing modules whose name is stored in registry eg. pythoncom/pywintypes. import ihooks ihooks.install() import pythoncom This code will fail inside pythonwin ide too ! ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110637&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:23:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:23:37 -0700 Subject: [Python-bugs-list] [Bug #110829] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <200008061723.KAA00374@bush.i.sourceforge.net> Bug #110829, was updated on 2000-Aug-01 14:12 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Details: Jitterbug-Id: 166 Submitted-By: aa8vb@ipass.net Date: Wed, 22 Dec 1999 07:57:58 -0500 (EST) Version: 1.5.2 OS: Irix In implementing a Python reader for VPF GIS data, I noticed that the struct module makes it very easy to read in data that may be in a different byte order than the local machine: val = struct.unpack( "" byte order prefixes used in the struct module were added to the array module. Thanks, Randall ==================================================================== Audit trail: Wed Jan 12 18:16:54 2000 guido changed notes Wed Jan 12 18:16:54 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:12 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 09:30:21 -0500 > In implementing a Python reader for VPF GIS data, I noticed that the struct > module makes it very easy to read in data that may be in a different byte > order than the local machine: > > val = struct.unpack( " > This parses from a little-endian file/buffer, and swaps bytes "if needed" to > the endianness of the local machine. > > However, using the array module is not so convenient. The developer has to > write code to sense the byte order of the local machine, and tell the > array module whether or not to swap bytes. I.e. there is no > "swap to native byte order" functionality: > > def _IsByteSwapNeeded( file_byte_order ): > """ The array module doesn't do byte swapping to the native byte order. > So we have to get under the hood and check it ourselves. > """ > def host_endian(): > if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' > else: return 'M' (I presume 'L' is little-endian, but what does 'M' stand for?) > assert file_byte_order in 'LM' > return ( host_endian() != file_byte_order ) > > a = array.array( "l", buf ) > if _IsByteSwapNeeded( 'L' ): > a.byteswap() > val = a.tolist() > > > The reason for using the array module (versus the struct module with > repeat counts) is for more efficient memory storage and access of large > numbers of lists containing large numbers of coordinates. struct insists > on converting everything at once, and the length must be exactly right. > array provides direct access to the any element of slice of a list so it > is my preferred choice. > > It would be useful if the "<" and ">" byte order prefixes used > in the struct module were added to the array module. You're right that this is more work than it should be. However I don't think that adding '<' to the format string is the right solution -- the format string declares the format of the data in the array, not how it should be converted from elsewhere. (The array module has other uses besides I/O of binary data.) I can see several solutions: - Add a byte order indicator to some standard module (e.g. the array module, or the sys module) so you can write a = array.array("l", buf) if sys.byte_order == 'big': a.byteswap() - Add a byte order flag to all the array methods that add raw data to the array object (constructor, fromfile(), fromstring(); and for symmetry also to the methods that write raw data out (tofile(), tostring()). A problem with tofile() is that in order to do the byteswap we'd either have to allocate temporary memory or byteswap in place, and then byteswap back after writing. I vote for the byte order indicator, giving total control to the user. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: "Fred L. Drake, Jr." Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 10:43:32 -0500 (EST) guido@cnri.reston.va.us writes: > I vote for the byte order indicator, giving total control to the user. I agree, but I'd also like to see an indicator for the native byte order somewhere (like sys) as well. (How possible would this be for JPython, Barry?) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 11:45:34 -0500 > guido@cnri.reston.va.us writes: > > I vote for the byte order indicator, giving total control to the user. > > I agree, but I'd also like to see an indicator for the native byte > order somewhere (like sys) as well. (How possible would this be for > JPython, Barry?) Ack! I was ambiguous! I meant to see a native byte order somewhere! --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: "Barry A. Warsaw" Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 11:59:07 -0500 (EST) >>>>> "Fred" == writes: Fred> I agree, but I'd also like to see an indicator for the Fred> native byte order somewhere (like sys) as well. (How Fred> possible would this be for JPython, Barry?) Java's native format is bigendian, regardless of the system's underlying endian-ness. I'm not aware of any way of figuring out what the system's endian-ness is. -Barry ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: Randall Hopper Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Thu, 30 Dec 1999 19:19:09 -0500 Guido van Rossum: |Randall Hopper: |> However, using the array module is not so convenient. The developer has to |> write code to sense the byte order of the local machine, and tell the |> array module whether or not to swap bytes. I.e. there is no |> "swap to native byte order" functionality: |> |> def _IsByteSwapNeeded( file_byte_order ): |> """ The array module doesn't do byte swapping to the native byte order. |> So we have to get under the hood and check it ourselves. |> """ |> def host_endian(): |> if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' |> else: return 'M' | |(I presume 'L' is little-endian, but what does 'M' stand for?) L/M - LSB/MSB - [L]east/[M]ost Significant Byte First though: L/B - [L]ittle/[B]ig Endian might have been more intuitive. |However I don't think that adding '<' to the format string is the |right solution -- the format string declares the format of the data in |the array, not how it should be converted from elsewhere. (The array |module has other uses besides I/O of binary data.) ... |I can see several solutions: |- Add a byte order indicator to some standard module (e.g. the array | module, or the sys module) so you can write a = array.array("l", buf) if | sys.byte_order == 'big': a.byteswap() |- Add a byte order flag to all the array methods that add raw data to | the array object (constructor, fromfile(), fromstring(); and for | symmetry also to the methods that write raw data out (tofile(), | tostring()). A problem with tofile() is that in order to do the | byteswap we'd either have to allocate temporary memory or byteswap in | place, and then byteswap back after writing. Having considered this again from what you've said, I agree that a byte order indicator would probably be better for the array case. I see your point: temporary buffers for reads or writes would be needed since array is a type used for storage whereas struct is not. A byte order indicator leads to more user code in doing the byte swapping and is inconsistent with struct's, but it does avoid all (potentially large) temporary buffer generation whether byte swapping is needed or not, which is important. Thanks, Randall ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: Actually, all we need is a simpler way to discover the native byte order. A flag in the struct module would do just fine. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110829&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:34:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:34:16 -0700 Subject: [Python-bugs-list] [Bug #110822] TCL_LIBRARY variable for win32 (PR#130) Message-ID: <200008061734.KAA00671@bush.i.sourceforge.net> Bug #110822, was updated on 2000-Aug-01 14:10 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Fixed Bug Group: Feature Request Priority: 4 Summary: TCL_LIBRARY variable for win32 (PR#130) Details: Jitterbug-Id: 130 Submitted-By: grant.griffin@alliedsignal.com Date: Mon, 15 Nov 1999 15:26:44 -0500 (EST) Version: 1.5.2 OS: Windows NT 4.0 I would like to suggest that the "TCL_LIBRARY" variable be automatically set by the Win32 installer program. Currently, this is a manual process. It can be frustrating for the user because when he tries to run a Tkinter program, it says "cannot find tcl80.dll...". (I was able to figure out the solution here only by digging through comp.lang.python in Deja.) Therefore, I recommend the installer be changed as follows: 1) Do TCL installation before Python, not after. 2) Somehow figure out what the value of TCL_LIBRARY should be as a function of the directory that the user had installed TCL in. 3) Automatically write the proper value of TCL_LIBRARY into the Windows registry. Alternatively, you could just add a prompt like "In order to use TCL with Python, you must set the 'TCL_LIBRARY' environment variable to point to the directory where tcl80.dll is installed." Anyway, thanks, guys--keep up the GREAT work! -Grant ==================================================================== Audit trail: Tue Nov 16 13:58:27 1999 guido changed notes Tue Nov 16 13:58:27 1999 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] TCL_LIBRARY variable for win32 (PR#130) Date: Mon, 15 Nov 1999 15:35:20 -0500 > I would like to suggest that the "TCL_LIBRARY" variable be automatically set by > the Win32 installer program. Currently, this is a manual process. It can be > frustrating for the user because when he tries to run a Tkinter program, it says > "cannot find tcl80.dll...". (I was able to figure out the solution here only by > digging through comp.lang.python in Deja.) > > Therefore, I recommend the installer be changed as follows: > > 1) Do TCL installation before Python, not after. > 2) Somehow figure out what the value of TCL_LIBRARY should be as a function of > the directory that the user had installed TCL in. > 3) Automatically write the proper value of TCL_LIBRARY into the Windows > registry. > > Alternatively, you could just add a prompt like "In order to use TCL with > Python, you must set the 'TCL_LIBRARY' environment variable to point to the > directory where tcl80.dll is installed." > > Anyway, thanks, guys--keep up the GREAT work! Thanks for the suggestion. The problem is that on Windows 95/98, the environment is not kept in the registry! Editing autoexec.bat has been suggested but is too error-prone. But we will definitely revisit this problem again with the next release (not due until late 2000); the best solution we can think of is to integrate the Tcl files in the Python installation instead of running the Tcl installer; this way we can be sure that Tcl is always in the same directory as Python. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: We will try to fgix this for Python 1.6. ------------------------------------------------------- Date: 2000-Aug-06 10:11 By: twouters Comment: Partly (or completely ?) resolved by including Tcl/Tk in the Python Installer for Windows. ------------------------------------------------------- Date: 2000-Aug-06 10:34 By: gvanrossum Comment: Yes, this is fixed in the 1.6 windows installation (through a helper module FixTk.py which is imported by importing Tkinter). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110822&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:39:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:39:50 -0700 Subject: [Python-bugs-list] [Bug #110669] Tkinter: widget.bind('sequence') incorrect (PR#368) Message-ID: <200008061739.KAA00839@bush.i.sourceforge.net> Bug #110669, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Wont Fix Bug Group: Not a Bug Priority: 5 Summary: Tkinter: widget.bind('sequence') incorrect (PR#368) Details: Jitterbug-Id: 368 Submitted-By: rozen@rgv.hp.com Date: Fri, 23 Jun 2000 15:31:19 -0400 (EDT) Version: 1.5.2 OS: Linux With Tcl/Tk, bind tag sequence returns the string which is the command. With Python, widget.bind('sequence') seems to return a reference to the command not the command. The following reproduces the problem on my machine. Try running the file and observe the print output. Pretty strange. #! /usr/bin/env python from Tkinter import * root = Tk() def init(): pass def greeting(str): import Dialog Dialog.Dialog(title="greetings", text=str, bitmap="",default=0,strings=("cont",)) class New_Toplevel_1: def __init__(self, master=None): self.ent17 = Entry (master) self.ent17.place(in_=master,x=45,y=50) self.ent17.configure(background="plum") self.ent17.configure(font="helvetica 14 bold") self.ent17.configure(foreground="black") self.ent17.configure(insertbackground="black") self.ent17.configure(selectbackground="black") self.ent17.configure(selectforeground="ivory") self.hello = StringVar() self.ent17.configure(textvariable=self.hello) self.ent17.configure(width="35") self.ent17.bind('q',lambda e: greeting('q')) x = self.ent17.bind() print 'x =', x x = self.ent17.bind('q') print 'x =', x # I expected x to be "lambda e: greeting('q')" # I actually got the following # x = set _tkinter_break [135926416 %# %b %f %h %k %s %t %w %x %y %A %E %K %N %W %T %X %Y] # if {"$_tkinter_break" == "break"} break def vp_start_gui(): global w root.title('New_Toplevel_1') root.geometry('500x200+216+41') root.configure(bg='wheat') w = New_Toplevel_1 (root) root.mainloop() if __name__ == '__main__': vp_start_gui() ==================================================================== Audit trail: Tue Jul 11 08:24:20 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Tkinter: widget.bind('sequence') incorrect (PR#368) Date: Fri, 23 Jun 2000 15:46:04 -0500 > With Tcl/Tk, bind tag sequence returns the string which is the command. > With Python, widget.bind('sequence') seems to return a reference to the > command not the command. > > The following reproduces the problem on my machine. Try running the file > and observe the print output. Pretty strange. The string returned is in fact the command bound -- this is a wrapper function. Since (typically) the argument to bind is a Python function, not a Tcl command, a wrapper is used to pass the event data to the Python function. This doesn't qualify as a bug -- it's just different. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-06 10:39 By: twouters Comment: Like Guido said, not a bug, just different. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110669&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:53:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:53:34 -0700 Subject: [Python-bugs-list] [Bug #110708] bug in time.sleep (PR#64) Message-ID: <200008061753.KAA01324@bush.i.sourceforge.net> Bug #110708, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in time.sleep (PR#64) Details: Jitterbug-Id: 64 Submitted-By: ddula@atl.mediaone.net Date: Wed, 25 Aug 1999 14:02:51 -0400 (EDT) Version: 152c1 OS: Debian Alpha Linux (potato) 2.2.1 This is a interesting bug that seems to have started after I upgraded to debian potato from slink. It must be a library related bug but this report might help somebody troubleshoot. At first I thought it was a bug in threading because it prevented the solaris hack sleep from returning thus my thread.start() never returned. But further digging show that import time time.sleep(0.1) # will always hang on on this platform Work around is to always sleep at least one second - I will do some more looking at the time class when I get a chance. Dave Dula ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:15 1999 guido changed notes For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110708&group_id=5470 From noreply@sourceforge.net Sun Aug 6 18:54:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 10:54:55 -0700 Subject: [Python-bugs-list] [Bug #110631] Debugger (win and idle) (PR#283) Message-ID: <200008061754.KAA01342@bush.i.sourceforge.net> Bug #110631, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Debugger (win and idle) (PR#283) Details: Jitterbug-Id: 283 Submitted-By: musingattheruins@yahoo.com Date: Mon, 10 Apr 2000 12:30:44 -0400 (EDT) Version: 1.5.2 OS: Win32 The python debugger (both Idle and PythonWin) does not undertand packages. Can run scripts from the command line that cannot be run in the debugger... Create package 'Test' in the directory "My Modules", add an __init__.py (empty) to the directory "My modules\Test", create file testfile.py with the contents... class TheTest: def __init__(self): self.i = 1 def go(self): return self.i Add the path to the Python path with the following file (test.reg)... REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\1.5\PythonPath\TheTest] @="C:\\My modules" then try the following at the python prompt: import Test.testfile j = Test.testfile.TheTest() k = j.go runs fine right? Yes it does, now step through it in the debugger and you get... import Test.testfile j = Test.testfile.TheTest() #exception: attribute 'TheTest' k = j.go Does not appear to be realted to the class (you can change it to a 'function in a module' instead of a 'method in a class in a module' and you get the a similar result.) Debugger does not understand packages. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110631&group_id=5470 From noreply@sourceforge.net Sun Aug 6 19:36:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 11:36:15 -0700 Subject: [Python-bugs-list] [Bug #111203] 1.6b1 build (docs?) pyexpat problem on Windows Message-ID: <200008061836.LAA27908@delerium.i.sourceforge.net> Bug #111203, was updated on 2000-Aug-06 11:36 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: 1.6b1 build (docs?) pyexpat problem on Windows Details: pyexpat is not documented as one of those subprojects needing external software, but apparently it is one; it needs xmlparse and xmltok, .h and .lib to build and .dll to run. The docs don't mention where to get those from, but I had them around (from a Perl site build...) and feeding them to the Python 1.6b1 build fixed it. So I think it's just a doc-bug. Alex For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111203&group_id=5470 From noreply@sourceforge.net Sun Aug 6 19:42:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 11:42:14 -0700 Subject: [Python-bugs-list] [Bug #111204] 1.6b1 test_winreg tries importing wrong module Message-ID: <200008061842.LAA28074@delerium.i.sourceforge.net> Bug #111204, was updated on 2000-Aug-06 11:42 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: 1.6b1 test_winreg tries importing wrong module Details: test_winreg.py has an import winreg which fails since no such module exists. Changing to: import _winreg lets the test succeed fully. Should the module be build as winreg, or is it a bug in test_winreg.py? Alex For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111204&group_id=5470 From noreply@sourceforge.net Sun Aug 6 20:21:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 12:21:24 -0700 Subject: [Python-bugs-list] [Bug #110677] PRIVATE: various minor Tkinter things (PR#388) Message-ID: <200008061921.MAA29341@delerium.i.sourceforge.net> Bug #110677, was updated on 2000-Jul-31 14:13 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PRIVATE: various minor Tkinter things (PR#388) Details: Jitterbug-Id: 388 Submitted-By: markus.oberhumer@jk.uni-linz.ac.at Date: Wed, 5 Jul 2000 09:38:11 -0400 (EDT) Version: python CVS OS: all Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter. Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll Canvas.CanvasItem & Canvas.Group: - bind lacks an optional "add" param - unbind lacks an optional "funcid" param - tkraise/lower should call self.canvas.tag_XXXX - bbox() return value is inconsistent with Canvas.bbox() ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:13:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:13:22 -0700 Subject: [Python-bugs-list] [Bug #110706] Compile error (PR#44) Message-ID: <200008062013.NAA05906@bush.i.sourceforge.net> Bug #110706, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Compile error (PR#44) Details: Jitterbug-Id: 44 Submitted-By: rene@kronos.szabinet.hu Date: Sun, 1 Aug 1999 16:39:42 -0400 (EDT) Version: 1.5.2 OS: Linux Compile error with Python-1.5.2 on Linux Slackware 4.0, kernel 2.2.10-ac8, gcc 2.7.2.3, make 3.76.1 ./configure --prefix=/usr/local --with-threads && make ... ./socketmodule.c: In function `setipaddr': ./socketmodule.c:392: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:392: too many arguments to function `gethostbyname_r' ./socketmodule.c:392: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyname_ex': ./socketmodule.c:1471: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type ./socketmodule.c:1471: too many arguments to function `gethostbyname_r' ./socketmodule.c:1471: warning: assignment makes integer from pointer without a cast ./socketmodule.c: In function `PySocket_gethostbyaddr': ./socketmodule.c:1534: warning: passing arg 7 of `gethostbyaddr_r' from incompatible pointer type ./socketmodule.c:1534: too many arguments to function `gethostbyaddr_r' ./socketmodule.c:1534: warning: assignment makes integer from pointer without a cast make[1]: *** [socketmodule.o] Error 1 make: *** [Modules] Error 2 ==================================================================== Audit trail: Wed Aug 04 12:12:39 1999 guido moved from incoming to platformbug Mon Aug 30 12:37:34 1999 guido changed notes Mon Oct 25 15:15:46 1999 guido changed notes For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110706&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:15:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:15:13 -0700 Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324) Message-ID: <200008062015.NAA05944@bush.i.sourceforge.net> Bug #110644, was updated on 2000-Jul-31 14:10 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in PyLong_FromLongLong (PR#324) Details: Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:16:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:16:36 -0700 Subject: [Python-bugs-list] [Bug #110670] Win32 os.listdir raises confusing errors (PR#374) Message-ID: <200008062016.NAA05972@bush.i.sourceforge.net> Bug #110670, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Win32 os.listdir raises confusing errors (PR#374) Details: Jitterbug-Id: 374 Submitted-By: tpeters@beopen.com Date: Thu, 29 Jun 2000 02:25:18 -0400 (EDT) Version: 1.6a2 OS: Windows Copying this over from the SourceForge bug manager: https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=108381 Here's the original complaint: On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Here's confirmation under Win98 1.6a2: C:\Python16>python Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> os.listdir('/cow') Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 3] No such process: '/cow' >>> ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110670&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:21:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:21:49 -0700 Subject: [Python-bugs-list] [Bug #110665] Compiling python on hpux 11.00 with threads (PR#360) Message-ID: <200008062021.NAA06148@bush.i.sourceforge.net> Bug #110665, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Compiling python on hpux 11.00 with threads (PR#360) Details: Jitterbug-Id: 360 Submitted-By: philipp.jocham@salomon.at Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT) Version: 1.5.2 OS: HP-UX 11.00 There are two missing details in the configure process to make this work out of the box. First: The function pthread_create isn't found in library libpthread.a but in libcma.a, because pthread_create is just a macro in sys/pthread.h pointing to __pthread_create_system After patching ./configure directly and running ./configure --with-thread (now detecting the correct library /usr/lib/libpthread.a) I also added -lcl to Modules/Makefile at LIBS= -lnet -lnsl -ldld -lpthread -lcl otherwise importing of modules with threads didn't work (in this case oci_.sl from DCOracle). I'm not sure about the correct syntax or wether it's the correct place and method, but I would suggest a solution like the following code snippet. [...] AC_MSG_CHECKING(for --with-thread) [...] AC_DEFINE(_POSIX_THREADS) LIBS="$LIBS -lpthread -lcl" LIBOBJS="$LIBOBJS thread.o"], [ AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD) [...] I hope this helps to make installation process smoother. Fell free to contact me, if there are further questions. Philipp -- I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. ==================================================================== Audit trail: Tue Jul 11 08:26:01 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110665&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:34:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:34:28 -0700 Subject: [Python-bugs-list] [Bug #110689] PRIVATE: Extra space bug in readline/rlcompleter/raw_input? (PR#45) Message-ID: <200008062034.NAA06608@bush.i.sourceforge.net> Bug #110689, was updated on 2000-Jul-31 14:15 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Wont Fix Bug Group: Not a Bug Priority: 5 Summary: PRIVATE: Extra space bug in readline/rlcompleter/raw_input? (PR#45) Details: Jitterbug-Id: 45 Submitted-By: skip@mojam.com Date: Wed, 4 Aug 1999 11:55:04 -0400 (EDT) Version: 1.5.2 OS: Linux I just tried using the readline/rlcompleter stuff in my own program for the first time. I noticed that when using the completion key to complete an input from a set of choices it tacks on an extra space to the end of the string. This seems like a bug to me. There's no way for the program to know if the enter typed the space explicitly or if it was appended by raw_input(). Is this perhaps a readline bug? I haven't delved into the source code at this point. Here's a script that demonstrates the problem. Try running it three times, once entering s TAB RET once entering spam RET and once entering spam SPC RET You will see that the first and third cases are indistinguishable. #!/usr/bin/env python import string, readline, rlcompleter, sys class Completer: def __init__(self): self.list = [] def complete(self, text, state): if state == 0: self.matches = self.get_matches(text) try: return self.matches[state] except IndexError: return None def set_choices(self, list): self.list = list def get_matches(self, text): matches = [] for elt in self.list: if string.find(elt, text) == 0: matches.append(elt) return matches completer = Completer() def select_from_list(list): completer.set_choices(list) readline.parse_and_bind("tab: complete") readline.set_completer(completer.complete) sys.stderr.write("Select from [%s]: " % string.join(list, "|")) result = raw_input() return result result = select_from_list(["spam", "ham", "eggs", "juice"]) print `result`, ord(result[-1]) ==================================================================== Audit trail: Wed Aug 04 12:12:40 1999 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] PRIVATE: Extra space bug in readline/rlcompleter/raw_input? (PR#45) Date: Wed, 04 Aug 1999 12:09:13 -0400 > I just tried using the readline/rlcompleter stuff in my own > program for the first time. I noticed that when using the > completion key to complete an input from a set of choices it > tacks on an extra space to the end of the string. This seems > like a bug to me. There's no way for the program to know if the > enter typed the space explicitly or if it was appended by > raw_input(). Is this perhaps a readline bug? I haven't delved > into the source code at this point. As far as I know this is a problem with the completion strategy hardcoded in the GNU readline code. I don't know of a fix. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-06 13:34 By: twouters Comment: I agree with Guido: the extra space is added by Readline, for the simple purpose of distinguishing between a successful, unambiguous completion, and a half-finished completion that stopped at the first 'junction'. In other words, in the 'namespace' containing 'eggs', 'spamandham' and 'spamandeggs', eg will complete to 'eggs' because it's a finished completion, but spa will complete to 'spamand', (without a space), so you know you have more possible completions. If you disambiguate by continuing it with 'h', and then press TAB again, it gets expanded into 'spamandham'. One possible solution is to never return a single possibility, but always a dummy possibility as well. Not very pretty, and not very nice if you use TABTAB (list all possible completions) but it should work. The other solutions is to provide a replacement for readline :-) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110689&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:37:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:37:46 -0700 Subject: [Python-bugs-list] [Bug #110686] cStringIO lacks the readlines method (PR#409) Message-ID: <200008062037.NAA06749@bush.i.sourceforge.net> Bug #110686, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 4 Summary: cStringIO lacks the readlines method (PR#409) Details: Jitterbug-Id: 409 Submitted-By: pierre@saiph.com Date: Sun, 23 Jul 2000 13:41:59 -0400 (EDT) Version: 1.5.2 OS: sparc solaris cStringIO is supposed to be the C version of For some reason, it does not provide the readlines method. The obvious turnaround is to use StringIO instead: no hurry to fix, at least on my side. ==================================================================== Audit trail: Mon Jul 24 18:41:02 2000 jeremy moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110686&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:43:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:43:06 -0700 Subject: [Python-bugs-list] [Bug #110842] dl.RTLD_GLOBAL missing (PR#313) Message-ID: <200008062043.NAA06932@bush.i.sourceforge.net> Bug #110842, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: dl.RTLD_GLOBAL missing (PR#313) Details: Jitterbug-Id: 313 Submitted-By: loewis@informatik.hu-berlin.de Date: Thu, 4 May 2000 09:54:13 -0400 (EDT) Version: 1.5.2 OS: Solaris The dl module does not support all flags to dlopen available on a specific system; eg. dl.open("foo.so",dl.RTLD_GLOBAL) does not work. On Solaris, the following constants are defined, in addition RTLD_NOLOAD RTLD_GLOBAL RTLD_LOCAL RTLD_PARENT RTLD_GROUP RTLD_WORLD RTLD_NODELETE ==================================================================== Audit trail: Mon May 22 17:25:17 2000 guido moved from incoming to request For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110842&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:50:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:50:05 -0700 Subject: [Python-bugs-list] [Bug #110680] bad pos value on match object (PR#397) Message-ID: <200008062050.NAA07114@bush.i.sourceforge.net> Bug #110680, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: bad pos value on match object (PR#397) Details: Jitterbug-Id: 397 Submitted-By: jeremy@beopen.com Date: Thu, 13 Jul 2000 21:42:47 -0400 (EDT) Version: CVS Thu Jul 13 21:43:09 EDT 2000 OS: The pos attribute of a match object is supposed to match the value of the optional pos argument passed to match or search. The default value of the argument is zero. The current implementation sets pos to be the start of the match instead. This program demonstrates: import re buf = "abcdef" rx = re.compile("b(c)") mo = rx.search(buf) print mo.pos, mo.endpos print mo.start(1), mo.end(1) bitdiddle:/tmp> python1.5 retest.py 0 6 2 3 bitdiddle:/tmp> python retest.py 1 6 2 3 ==================================================================== Audit trail: Fri Jul 14 11:35:54 2000 jeremy moved from incoming to open Follow-Ups: Date: 2000-Aug-06 13:50 By: twouters Comment: Jeremy, this looks fixed. (I get the '1.5' behaviour in both 'sre' and 'pre' in current CVS snapshots.) Please re-open this bugreport (and assign to effbot, I assume) if you still see the bug (and mark it platform-dependant -- I don't see it on BSDI or Linux, in any case.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110680&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:53:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:53:24 -0700 Subject: [Python-bugs-list] [Bug #110664] PRIVATE: Bug in re module (PR#36) Message-ID: <200008062053.NAA07267@bush.i.sourceforge.net> Bug #110664, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PRIVATE: Bug in re module (PR#36) Details: Jitterbug-Id: 36 Submitted-By: chenna@embl-heidelberg.de Date: Fri, 23 Jul 1999 06:51:43 -0400 (EDT) Version: 1.5.1 OS: OSF1 Hello I get Stack overflow: pid 14731, proc emparse1.py, addr 0x11fdfffd8, pc 0x120068cd8 Segmentation fault when I run the following. The problem is re module unable to search for the pattern that is too large, but this is a requirement for my application in biology. I enclose the source code with this. Please email me the solution as soon as possible Thanks Ramu ___________________________ #!/usr/pub/bin/python1.5 # # # # (C) Chenna Ramu, EMBL, Heidelberg, Germany # # parser for biological databases # import string import sys import re parserDict = { 'id' : r'((^ID [^\n]+\n)+)' , 'ac' : r'((^AC [^\n]+\n)+)' , 'dt' : r'((^DT [^\n]+\n)+)' , 'de' : r'((^DE [^\n]+\n)+)' , 'gn' : r'((^GN [^\n]+\n)+)' , 'os' : r'((^OS [^\n]+\n)+)' , 'oc' : r'((^OC [^\n]+\n)+)' , 'ref' : r'((' r'(^RN [^\n]+\n)' r'((^RP [^\n]+\n)+)' r'((^RX [^\n]+\n)?)' r'((^RA [^\n]+\n)+)' r'((^RT [^\n]+\n)*)' r'((^RL [^\n]+\n)+)' r')+)', 'cc' : r'((^CC [^\n]+\n)+)' , 'dr' : r'((^DR [^\n]+\n)+)' , 'kw' : r'((^KW [^\n]+\n)+)' , 'ft' : r'((^FT [^\n]+\n)+)' , 'sq' : r'(^SQ [^\n]+\n)' \ r'((^ [^\n]+\n)+)' } _hrefLink = {'embl':['%s','^DR ([^;]+)']} #should be like this hrefLink = {'EMBL':"%s", 'MIM':"%s"} em_rep = r'(^DR )(?P[^;]+); (?P[^;]+)' class embl: def __init__(self,parserDict={}): self.parserDict = {} self.reDict = {} #keep the compiled re's self.fields = [] if parserDict: self.Init(parserDict) def Init(self,parserDict): self.parserDict = parserDict self.fields = parserDict.keys() for j in self.fields: setattr(self, j, None) self.reDict[j] = re.compile(parserDict[j],re.MULTILINE) def Parse(self,str): if not self.parserDict: print "No parser specified" return for k,v in parserDict.items(): ## tmp = re.compile(v,re.MULTILINE) # move this to __init__ tmp = self.reDict[k] mat = tmp.search(str) if mat: setattr(self, k, mat.group() ) def Field(self,name): try: return getattr(self,name) except AttributeError: return None def PrintFields(self): flds = self.fields for j in flds: print "==> ",j print getattr(self,j) def ReParse(self,str,retToken,pat): """ str:string to parse, retToken:return token, pat:parser """ _p = re.compile(pat) m = _p.search(str) if m: return m.group(retToken) else: return None def Href(match): """ Replaces the hrefs """ dbase = match.group('dbase') id = match.group('id') try: defi = hrefLink[dbase] except KeyError: defi = None if defi: tmp = match.group(1) + dbase + '; '+defi %(dbase,id,id) else: tmp = match.group(1)+ dbase + '; ' + id return tmp def test(fileName): sys.path.insert(0,'/home/chenna/py') ## from seqFormat import * e = embl(parserDict) # f = open('acha_mouse.dat','r') f = open(fileName,'r') a = f.readlines() f.close() a = string.join(a,'') e.Parse(a) e.PrintFields() import string print ' the fields are ',e.fields ## seq = string.split(e.sq,';')[-1] ## s = Seq(seq,'test') ## print 'check===>',s.seq ## s.SeqPrint('swiss') seqLen = e.ReParse(e.sq[0:50],'seqLen',r'^SQ [^ ]+ *(?P(\d+))') print e.sq print "length of the sequence ",seqLen print e.ref dr = e.dr print dr p = re.compile(em_rep,re.M) dr = p.sub(Href,dr) print dr print e.Field('id') print e.Field('dr') print e.Field('mm') return def test1(dumm=None): tmp = ['SQ Sequence 1041931 BP; 8972 A; 5950 C; 6264 G; 8224 T; 0 other;\n'] for j in range(1,17365): t = ' ' + 'tcagtcagtg ' * 6 + '\n' tmp.append(t) a = string.join(tmp) e = embl(parserDict) e.Parse(a) e.PrintFields() if __name__ == '__main__': try: test1(sys.argv[1]) except: test1() ==================================================================== Audit trail: Sat Jul 24 16:53:53 1999 guido changed notes Sat Jul 24 16:53:53 1999 guido moved from incoming to open Sat Jul 24 17:04:17 1999 guido changed notes Follow-Ups: Date: 2000-Aug-06 13:53 By: twouters Comment: Fair chance this is already fixed, either in 1.5.2 remodule, or in the new 'sre' by Fredrik. Maybe /F can say something useful here. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110664&group_id=5470 From noreply@sourceforge.net Sun Aug 6 21:56:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 13:56:35 -0700 Subject: [Python-bugs-list] [Bug #110673] win32api.GetFullPathName (build 129) (PR#380) Message-ID: <200008062056.NAA07318@bush.i.sourceforge.net> Bug #110673, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: win32api.GetFullPathName (build 129) (PR#380) Details: Jitterbug-Id: 380 Submitted-By: 2jerry@writeme.com Date: Mon, 3 Jul 2000 17:14:02 -0400 (EDT) Version: 1.5.2 (win32api build 129) OS: pc win98 next to code: full_path_lst = map(os.path.abspath, sys.path) according to that sys.path include the source directory at the first place of sys.path. I noticed that if I call the module in its own directory (python -i module.py) the first item of sys.path is ''. That all ok: abspath function in os module call getcwd() function if path is Null. ... good day for UNIX like men (as me :)) ... but in NT or WIN 98 workstation: os.path.abspath call :win32api.GetFullPathName(path) in ntpath module and win32api.GetFullPathName('') return '' and not current directory. Maybe is it a functionality .. but is os-depend functionality available for a longtime ? Jerome.vacher alias Jerry the foolish dracomorpheus. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 16:19:30 +1000 Can anyone else here confirm that: a) os.abspath('') on Linux does indeed return the CWD. b) It is supposed to :-) If confirmed, this would be a bug in ntpath.py. It catches win32api exceptions, and returns the input name in that case. This would be triggered by: >>> win32api.GetFullPathName('') Traceback (most recent call last): File "", line 1, in ? pywintypes.api_error: (127, 'GetFullPathName', 'The specified procedure could not be found.') Is this indeed something we should fix? Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > 2jerry@writeme.com > Sent: Tuesday, 4 July 2000 7:14 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) > (PR#380) > > > Full_Name: Jerome VACHER > Version: 1.5.2 (win32api build 129) > OS: pc win98 > Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55) > > > next to code: > full_path_lst = map(os.path.abspath, sys.path) > > according to that sys.path include the source directory at the > first place of > sys.path. > > I noticed that if I call the module in its own directory (python > -i module.py) > the first item of sys.path is ''. > That all ok: abspath function in os module call getcwd() > function if path is > Null. > ... > good day for UNIX like men (as me :)) > ... > but in NT or WIN 98 workstation: > os.path.abspath call :win32api.GetFullPathName(path) in ntpath module > and > win32api.GetFullPathName('') return '' and not current directory. > > Maybe is it a functionality .. but is os-depend functionality > available for a > longtime ? > > Jerome.vacher alias Jerry the foolish dracomorpheus. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: "Fred L. Drake, Jr." Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 13:34:24 -0400 (EDT) Mark Hammond writes: > Can anyone else here confirm that: > > a) os.abspath('') on Linux does indeed return the CWD. Yes, that's right. > b) It is supposed to :-) I think that's the right thing to do. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member ------------------------------------------------------- Date: 2000-Aug-06 13:56 By: twouters Comment: Possibly already fixed, or at least Mark has looked at it :) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110673&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:10:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:10:15 -0700 Subject: [Python-bugs-list] [Bug #110837] Tkinter Optionmenu doesn't accept 'font' resource (PR#229) Message-ID: <200008062110.OAA00358@delerium.i.sourceforge.net> Bug #110837, was updated on 2000-Aug-01 14:14 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Wont Fix Bug Group: Feature Request Priority: 5 Summary: Tkinter Optionmenu doesn't accept 'font' resource (PR#229) Details: Jitterbug-Id: 229 Submitted-By: aa8vb@yahoo.com Date: Thu, 9 Mar 2000 08:57:50 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 menu = apply( OptionMenu, ( parent, var ) + tuple( option_names ), { 'font':PANEL_FONT } ) generates: TypeError: unexpected keyword argument: font It would be helpful if the 'font' resource were accepted and used to create the menubutton and child command widgets. In its absense, folks need to poke at the internals of OptionMenu (obviously not a good idea) or establish a parent frame for each option menu with a unique name and use option_add to stuff *Class*Font: resources into the Tk resource database. If the 'font' option were supported, it would simplify this greatly. Thanks, Randall ==================================================================== Audit trail: Mon Apr 03 18:37:34 2000 guido changed notes Mon Apr 03 18:37:34 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:14 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Tkinter Optionmenu doesn't accept 'font' resource (PR#229) Date: Thu, 09 Mar 2000 10:45:55 -0500 > It would be helpful if the 'font' resource were accepted and used to > create the menubutton and child command widgets. Unfortunately, the underlying Tk command, tk_optionmenu, doesn't support this. Nothing I can do about it. (See http://dev.scriptics.com/man/tcl8.3/TkCmd/optionMenu.htm.) --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:14 By: none Comment: Probably won't be done. ------------------------------------------------------- Date: 2000-Aug-06 14:10 By: twouters Comment: Not much Python can do, since it's a Tk limitation. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110837&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:12:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:12:55 -0700 Subject: [Python-bugs-list] [Bug #110853] Segmentation fault with kernel 2.2.12 (PR#103) Message-ID: <200008062112.OAA00402@delerium.i.sourceforge.net> Bug #110853, was updated on 2000-Aug-01 14:37 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Irreproducible Priority: 5 Summary: Segmentation fault with kernel 2.2.12 (PR#103) Details: Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux 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 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:37 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103) Date: Mon, 11 Oct 1999 23:09:13 -0400 > 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/) ------------------------------------------------------- Date: 2000-Aug-01 14:37 By: none Comment: Probably caused by a huge jump in Linux kernel version without recompiling Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110853&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:14:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:14:32 -0700 Subject: [Python-bugs-list] [Bug #110622] pdb bug (PR#236) Message-ID: <200008062114.OAA00517@delerium.i.sourceforge.net> Bug #110622, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: pdb bug (PR#236) Details: Jitterbug-Id: 236 Submitted-By: jsolbrig@webcom.com Date: Tue, 14 Mar 2000 19:55:22 -0500 (EST) Version: 1.5.2 OS: Win32/win95 pdb (python debugger) tends to drop (ignore) breaks in multi-file debugging. I wish I had time to isolate the offending code but I don't. ==================================================================== Audit trail: Mon May 22 17:37:26 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110622&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:25:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:25:13 -0700 Subject: [Python-bugs-list] [Bug #110625] trouble building under Solaris 7 (PR#260) Message-ID: <200008062125.OAA00809@delerium.i.sourceforge.net> Bug #110625, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: trouble building under Solaris 7 (PR#260) Details: Jitterbug-Id: 260 Submitted-By: lipman@helix.nih.gov Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST) Version: 1.5.2 OS: Solaris 7 106541-08 When I built Python on my machine: SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10 Python's internal symbols (for instance PySequence_Length) were not included in the dynamic symbol table of the python executable. This prevented the Numerical-15.2 extensions from importing properly. My machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker installed. I use the GNU linker, which is first in the $PATH under which Python was built. A workaround for this problem is to change the following line in Modules/Makefile.pre from LDFLAGS= to LDFLAGS= -export-dynamic This will only work for the GNU linker. ==================================================================== Audit trail: Mon May 22 17:39:59 2000 guido changed notes Mon May 22 17:39:59 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-06 14:25 By: twouters Comment: This might be fixed by newer autoconf ? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110625&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:28:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:28:07 -0700 Subject: [Python-bugs-list] [Bug #110840] -with-cxx option to configure script (PR#24) Message-ID: <200008062128.OAA00847@delerium.i.sourceforge.net> Bug #110840, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: -with-cxx option to configure script (PR#24) Details: Jitterbug-Id: 24 Submitted-By: guido@python.org Date: Wed, 14 Jul 1999 11:16:51 -0400 (EDT) Version: 1.5.2 OS: Unix Geoff Furnish has a patch for the configure script which might be reasonable. See http://www.python.org/sigs/c++-sig/sig_code.html ==================================================================== Audit trail: Wed Jul 14 11:18:10 1999 guido moved from incoming to request For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110840&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:30:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:30:42 -0700 Subject: [Python-bugs-list] [Bug #110844] Annoyance in ftpmirror.py script (PR#48) Message-ID: <200008062130.OAA00964@delerium.i.sourceforge.net> Bug #110844, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: Annoyance in ftpmirror.py script (PR#48) Details: Jitterbug-Id: 48 Submitted-By: mok@imsb.au.dk Date: Mon, 9 Aug 1999 10:27:00 -0400 (EDT) Version: 1.5.2 OS: Linux Linux 2.0.36 The script ftpmirror.py contains some useful (for me) routines, but the file cannot be imported unless the following (trivial) patch is applied 395c395,396 < main() --- > if __name__ == "__main__": > main() ==================================================================== Audit trail: Tue Aug 10 17:46:08 1999 guido moved from incoming to request For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110844&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:32:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:32:54 -0700 Subject: [Python-bugs-list] [Bug #110702] closing a popen file descriptor (PR#33) Message-ID: <200008062132.OAA00988@delerium.i.sourceforge.net> Bug #110702, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: closing a popen file descriptor (PR#33) Details: Jitterbug-Id: 33 Submitted-By: laik@cs.stanford.edu Date: Tue, 20 Jul 1999 14:00:11 -0400 (EDT) Version: 1.5.2 OS: Linux 2.2.10 I can't close a pipe's file descriptor without an error: >>> import os >>> p1 = os.popen("cat dummy1", "r") >>> p2 = os.popen("cat dummy2", "r") >>> p1.close() Traceback (innermost last): File "", line 1, in ? IOError: (0, 'Error') It only happens if I do two or more popens. If I try to close any file descriptor but the last one I opened, I get this mysterious IOError. It happens regardless of the order I try to close the descriptors. ==================================================================== Audit trail: Sat Jul 24 17:02:54 1999 guido sent reply 1 Sat Jul 24 17:03:22 1999 guido changed notes Sat Jul 24 17:03:22 1999 guido moved from incoming to open Sat Jul 24 17:05:25 1999 guido moved from open to platformbug Follow-Ups: Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: closing a popen file descriptor (PR#33) Date: Sat Jul 24 17:02:54 1999 > Full_Name: Kevin Lai > Version: 1.5.2 > OS: Linux 2.2.10 > Submission from: (NULL) (192.25.214.6) > > > I can't close a pipe's file descriptor without an error: > >>>> import os >>>> p1 = os.popen("cat dummy1", "r") >>>> p2 = os.popen("cat dummy2", "r") >>>> p1.close() > Traceback (innermost last): > File "", line 1, in ? > IOError: (0, 'Error') > > It only happens if I do two or more popens. If I try to close any file > descriptor > but the last one I opened, I get this mysterious IOError. It happens regardless > of the order I try to close the descriptors. Kevin, this works on other platforms I can try (Solaris 2.6, linux 2.0.34). One possibility is that the C library in the Linux version you are using has changed; the IOError means that its pclose() returns an error indicator. The (0, 'Error') message means that pclose() didn't set the errno variable. It could be a bug in the Linux C library, or a change in interface that requires Python to interpret the error return differently. Can you help us discover which is the case? Does the man page for pclose() say anything about this? Does this fail in an equivalent C program? --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: From: laik@tnt.Stanford.EDU Subject: Re: closing a popen file descriptor (PR#33) Date: Tue, 27 Jul 1999 01:41:15 -0700 Guido, Thanks for your quick reply. As far as I can tell, the man page for pclose() doesn't mention any API changes. I have included the popen() and wait4() man pages for the system I am using (PII 300, Linux 2.2.10, glibc 2.1.1). I have written a short C program which tries to exercise the bug. On my system, it gives these results: [laik@nebraska]~>gcc popen.c [laik@nebraska]~>a.out pclose(p1): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 pclose(p2): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 pclose(p3): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 On a Linux 2.0.33, glibc 2.0.7 system, it gives the same results. However, my system exhibits the problem under Python, while the other does not. I conclude that my C program doesn't mimic the Python program well enough to trigger the bug, but I don't know how to fix that. #include #define _USE_BSD #include #include #include main() { FILE *p1, *p2, *p3; int pc1, pc2, pc3; p1 = popen("ls", "r"); p2 = popen("ls", "r"); p3 = popen("ls", "r"); sleep(1); pc1 = pclose(p1); printf("pclose(p1): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc1, WIFEXITED(pc1), WEXITSTATUS(pc1), WIFSIGNALED(pc1)); pc2 = pclose(p2); printf("pclose(p2): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc1, WIFEXITED(pc2), WEXITSTATUS(pc2), WIFSIGNALED(pc2)); pc3 = pclose(p3); printf("pclose(p3): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc3, WIFEXITED(pc3), WEXITSTATUS(pc3), WIFSIGNALED(pc3)); } POPEN(3) Linux Programmer's Manual POPEN(3) NAME popen, pclose - process I/O SYNOPSIS #include FILE *popen(const char *command, const char *type); int pclose(FILE *stream); DESCRIPTION The popen() function opens a process by creating a pipe, forking, and invoking the shell. Since a pipe is by defi- nition unidirectional, the type argument may specify only reading or writing, not both; the resulting stream is cor- respondingly read-only or write-only. The command argument is a pointer to a null-terminated string containing a shell command line. This command is passed to /bin/sh using the -c flag; interpretation, if any, is performed by the shell. The mode argument is a pointer to a null-terminated string which must be either `r' for reading or `w' for writing. The return value from popen() is a normal standard I/O stream in all respects save that it must be closed with pclose() rather than fclose(). Writing to such a stream writes to the standard input of the command; the command's standard output is the same as that of the process that called popen(), unless this is altered by the command itself. Conversely, reading from a ``popened'' stream reads the command's standard output, and the command's standard input is the same as that of the process that called popen. Note that output popen streams are fully buffered by default. The pclose function waits for the associated process to terminate and returns the exit status of the command as returned by wait4. RETURN VALUE The popen function returns NULL if the fork(2) or pipe(2) calls fail, or if it cannot allocate memory. The pclose function returns -1 if wait4 returns an error, or some other error is detected. ERRORS The popen function does not set errno if memory allocation fails. If the underlying fork() or pipe() fails, errno is set appropriately. If the mode argument is invalid, and this condition is detected, errno is set to EINVAL. If pclose() cannot obtain the child status, errno is set to ECHILD. CONFORMING TO POSIX.2 BUGS Since the standard input of a command opened for reading shares its seek offset with the process that called popen(), if the original process has done a buffered read, the command's input position may not be as expected. Sim- ilarly, the output from a command opened for writing may become intermingled with that of the original process. The latter can be avoided by calling fflush(3) before popen. Failure to execute the shell is indistinguishable from the shell's failure to execute command, or an immediate exit of the command. The only hint is an exit status of 127. HISTORY A popen() and a pclose() function appeared in Version 7 AT&T UNIX. SEE ALSO fork(2), sh(1), pipe(2), wait4(2), fflush(3), fclose(3), fopen(3), stdio(3), system(3). BSD MANPAGE 7 May 1998 1 WAIT4(2) Linux Programmer's Manual WAIT4(2) NAME wait3, wait4 - wait for process termination, BSD style SYNOPSIS #define _USE_BSD #include #include #include pid_t wait3(int *status, int options, struct rusage *rusage) pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage) DESCRIPTION The wait3 function suspends execution of the current pro- cess until a child has exited, or until a signal is deliv- ered whose action is to terminate the current process or to call a signal handling function. If a child has already exited by the time of the call (a so-called "zom- bie" process), the function returns immediately. Any sys- tem resources used by the child are freed. The wait4 function suspends execution of the current pro- cess until a child as specified by the pid argument has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function. If a child as requested by pid has already exited by the time of the call (a so-called "zombie" pro- cess), the function returns immediately. Any system resources used by the child are freed. The value of pid can be one of: < -1 which means to wait for any child process whose process group ID is equal to the absolute value of pid. -1 which means to wait for any child process; this is equivalent to calling wait3. 0 which means to wait for any child process whose process group ID is equal to that of the calling process. > 0 which means to wait for the child whose process ID is equal to the value of pid. The value of options is a bitwise OR of zero or more of the following constants: WNOHANG which means to return immediately if no child is there to be waited for. WUNTRACED which means to also return for children which are stopped, and whose status has not been reported. If status is not NULL, wait3 or wait4 store status infor- mation in the location pointed to by status. This status can be evaluated with the following macros (these macros take the stat buffer (an int) as an argument -- not a pointer to the buffer!): WIFEXITED(status) is non-zero if the child exited normally. WEXITSTATUS(status) evaluates to the least significant eight bits of the return code of the child which terminated, which may have been set as the argument to a call to exit() or as the argument for a return state- ment in the main program. This macro can only be evaluated if WIFEXITED returned non-zero. WIFSIGNALED(status) returns true if the child process exited because of a signal which was not caught. WTERMSIG(status) returns the number of the signal that caused the child process to terminate. This macro can only be evaluated if WIFSIGNALED returned non-zero. WIFSTOPPED(status) returns true if the child process which caused the return is currently stopped; this is only possible if the call was done using WUNTRACED. WSTOPSIG(status) returns the number of the signal which caused the child to stop. This macro can only be evaluated if WIFSTOPPED returned non-zero. If rusage is not NULL, the struct rusage as defined in it points to will be filled with accounting information. See getrusage(2) for details. RETURN VALUE The process ID of the child which exited, -1 on error (in particular, when no unwaited-for child processes of the specified kind exist) or zero if WNOHANG was used and no child was available yet. In the latter two cases errno will be set appropriately. ERRORS ECHILD No unwaited-for child process as specified does exist. ERESTARTSYS if WNOHANG was not set and an unblocked signal or a SIGCHLD was caught. This error is returned by the system call. The library interface is not allowed to return ERESTARTSYS, but will return EINTR. CONFORMING TO SVr4, POSIX.1 SEE ALSO signal(2), getrusage(2), wait(2), signal(7) Linux 23 June 1997 1 ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: Perhaps a bug or interface change in Linux popen()? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110702&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:32:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:32:07 -0700 Subject: [Python-bugs-list] [Bug #110690] Bug in os.environ for Windows (PR#50) Message-ID: <200008062132.OAA00983@delerium.i.sourceforge.net> Bug #110690, was updated on 2000-Jul-31 14:15 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Bug in os.environ for Windows (PR#50) Details: Jitterbug-Id: 50 Submitted-By: bobalex@uppercase.xerox.com Date: Wed, 11 Aug 1999 19:19:16 -0400 (EDT) Version: 1.5.2 OS: WinNT os.environ for Windows appears to be a map-type object that converts its keys to upper case. Retrieval using a mixed case key works in some cases, but some overloaded "operators" don't seem to do the right thing unless I pass an all-upper-case key. E.g.: >>> os.environ["x"] = "y" # Stores pair {"X": "y"} >>> os.environ["x"] # Works, indicates an effort is made 'y' # to retrieve mixed case keys >>> os.environ.get("x", "NOT FOUND") # Doesn't see the key "x" 'NOT FOUND' >>> os.environ.get("X", "NOT FOUND") # Works with all-upper-case key 'y' >>> del os.environ["x"] # Doesn't see the key "x" Traceback (innermost last): File "", line 1, in ? File "E:\Program Files\Python\Lib\UserDict.py", line 16, in __delitem__ def __delitem__(self, key): del self.data[key] KeyError: x >>> del os.environ["X"] # Works with all-upper-case key ==================================================================== Audit trail: Mon Aug 30 12:33:44 1999 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110690&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:33:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:33:40 -0700 Subject: [Python-bugs-list] [Bug #110705] combination of socket.gethostbyname and os.system hangs program (PR#401) Message-ID: <200008062133.OAA01104@delerium.i.sourceforge.net> Bug #110705, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: combination of socket.gethostbyname and os.system hangs program (PR#401) Details: Jitterbug-Id: 401 Submitted-By: andyg@one.net.au Date: Mon, 17 Jul 2000 04:26:12 -0400 (EDT) Version: Python 1.5.2 (#3, Jun 29 2000, 15:52:04) [GCC 2.8.1] on sunos5 OS: SunOS psol002 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise A combination of socket.gethostbyname and os.system appears to hang python intermittently. We run Dec and Sun systems - it only appears to be a problem with sun systems. The following is the simplest way I can reproduce the problem: test.py: -------------------------------- #!/usr/local/bin/python import os import socket print socket.gethostbyname( "a hostname (but not localhost)" ) os.system("echo fred") hang.sh: -------------------------------- #!/bin/ksh while true ; do ./test.py done output: --------------------------------- 10.666.666.666 fred 10.666.666.666 fred ... eventually ... 10.666.666.666 If "a hostname" is "localhost" it doesn't hang. For anything else which it can successfully resolve, it seems to hang. Thanks ! Andy. ==================================================================== Audit trail: Mon Jul 24 18:39:07 2000 jeremy changed notes Mon Jul 24 18:39:07 2000 jeremy moved from incoming to platformbug For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110705&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:34:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:34:51 -0700 Subject: [Python-bugs-list] [Bug #110683] compiling on WinNT (PR#403) Message-ID: <200008062134.OAA01112@delerium.i.sourceforge.net> Bug #110683, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: compiling on WinNT (PR#403) Details: Jitterbug-Id: 403 Submitted-By: falk.lehmann@gmx.net Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT) Version: 1.6a2 OS: WinNT 4.0 I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. The compiler stops with some warnings and an error message: K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer is not a constant K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' : unreferenced local variable K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'char [4]' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047: 'initializing' : 'char *' differs in levels of indirection from 'unsigned int ' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl *)(struct _object *)' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047: 'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )' differs in levels of indirection from 'struct _object *(__cdecl *)(struct _object *,char *)' Thanks in advance for fixing (at least the error). Falk ==================================================================== Audit trail: Tue Jul 25 07:25:55 2000 guido changed notes Tue Jul 25 07:25:55 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 11:35:24 -0500 > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. Please try the current CVS tree (on its way to 2.0); we have no problems compiling this on VC 6.0. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: From: Falk Lehmann Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 13:46:45 -0500 [magical fwd by GvR] Guido, sorry, but forgot to write, that I switched on the USE_SSL macro. And then the _socket module does not compile. Falk > > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. > > Please try the current CVS tree (on its way to 2.0); we have no > problems compiling this on VC 6.0. > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) > ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 14:00:20 -0500 > sorry, but forgot to write, that I switched on the USE_SSL macro. > And then the _socket module does not compile. It appears that the Python SSL code hasn't been ported to Windows. We'll add this to our TODO list, but it's low priority... Perhaps you could give it a shot yourself? See www.python.org/patches/ for how to contribute. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: Windows compile fails when using openSSL. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110683&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:35:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:35:35 -0700 Subject: [Python-bugs-list] [Bug #110695] complexobject.c optimization error on SGI (PR#144) Message-ID: <200008062135.OAA01124@delerium.i.sourceforge.net> Bug #110695, was updated on 2000-Jul-31 14:28 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: complexobject.c optimization error on SGI (PR#144) Details: Jitterbug-Id: 144 Submitted-By: robert.harrison@pnl.gov Date: Fri, 3 Dec 1999 01:35:19 -0500 (EST) Version: 1.5.2 OS: IRIX64 6.5 On an SGI (IRIX64 6.5, MIPSpro Compilers: Version 7.3.1m, -n32) Python-1.5.2/Objects/complexobject.c does not compile correctly with optimization. The problem shows up as a bus error in PyComplex_ImagAsDouble when importing Numeric Python. All works fine when this one file is compiled with -O0 (-O1 and higher fail). I assume that this is probably just a compiler error. ==================================================================== Audit trail: Fri Dec 03 10:39:28 1999 guido changed notes Fri Dec 03 10:39:28 1999 guido moved from incoming to platformbug For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110695&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:36:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:36:06 -0700 Subject: [Python-bugs-list] [Bug #110870] Coredump in moduleobjectc.c:134 (PR#79) Message-ID: <200008062136.OAA01146@delerium.i.sourceforge.net> Bug #110870, was updated on 2000-Aug-01 14:42 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: Coredump in moduleobjectc.c:134 (PR#79) Details: Jitterbug-Id: 79 Submitted-By: ajung@sz-sb.de Date: Mon, 13 Sep 1999 07:29:09 -0400 (EDT) Version: 1.5.2 OS: Solaris 2.6/Sparc (ojs@bonnie:~/PROD/lib/site-python/ojs) 73 : !gdb gdb python core GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (sparc-sun-solaris2.4), Copyright 1996 Free Software Foundation, Inc... Core was generated by `python -v prod_descr.py'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libmp.so.2...done. Reading symbols from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1...done. Reading symbols from /ojs/home/ojs/PROD/lib/python1.5/site-packages/DateTime/mxDateTime/mxDateTime.so...done. #0 0x49220 in _PyModule_Clear (m=0xc76e4) at moduleobject.c:134 134 if (value != Py_None && PyString_Check(key)) { (gdb) bt #0 0x49220 in _PyModule_Clear (m=0xc76e4) at moduleobject.c:134 #1 0x29fe4 in PyImport_Cleanup () at import.c:308 #2 0x30d18 in Py_Finalize () at pythonrun.c:206 #3 0x21c8c in Py_Main (argc=3, argv=0xeffff964) at main.c:298 #4 0x216e4 in main (argc=3, argv=0xeffff964) at python.c:12 I get the traceback above from a small module that contains just 2 import statements. One module contains just the declaration of 2 classes and the second module contains some dicts,lists...nothing special. When I change the order of both import statements in the main script no core dump occurs. Any idea ? Andreas ==================================================================== Audit trail: Wed Sep 15 23:50:12 1999 guido changed notes Wed Sep 15 23:50:12 1999 guido moved from incoming to irreproducible Thu Sep 16 10:15:31 1999 guido changed notes Thu Sep 16 10:15:32 1999 guido moved from irreproducible to 3rdpartybug Follow-Ups: Date: 2000-Aug-01 14:42 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Coredump in moduleobjectc.c:134 (PR#79) Date: Thu, 16 Sep 1999 10:04:18 -0400 > I was able to get more information. The problem might occur with the following code: > > * module.py* > > from prod_support import read_current_prodids > > PRODIDS = read_current_prodids() > > > * main.py * > > import module.py > > > When I run python on main.py I get the bus error. When I switch module.py to: > > import prod_support > PRODIDS = prod_support.read_current_prodids() > > everything is ok. The function read_current_prodids() uses DCOracle (Digicool/Zope). > I'm not sure if this causes the problem - I'll try to figure it out. Probably something in the prod_support module causes the problem. I'm quite sure the problem is not in Python itself, so the Python bugs list is not the place to report the bug. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:42 By: none Comment: Probably caused by DCOracle or other 3rd party extension. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110870&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:39:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:39:07 -0700 Subject: [Python-bugs-list] [Bug #110867] DCOracle select max() always returns integers (PR#289) Message-ID: <200008062139.OAA01273@delerium.i.sourceforge.net> Bug #110867, was updated on 2000-Aug-01 14:41 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: DCOracle select max() always returns integers (PR#289) Details: Jitterbug-Id: 289 Submitted-By: bchen@exelixis.com Date: Tue, 11 Apr 2000 18:52:54 -0400 (EDT) Version: 1.5.2 OS: SUN Solaris I am using DCOracle to retrieve the max and min values of an attribute from a database. The attribute contains floating point numbers. If I use select attr_name from table_name I got a list of floating point numbers. But if I call select max(attr_name) from table_name I always got integers. Can anyone help me figure out what's wrong? Thanks, Bin ==================================================================== Audit trail: Sat Jul 01 02:44:48 2000 fdrake moved from incoming to 3rdpartybug For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110867&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:39:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:39:24 -0700 Subject: [Python-bugs-list] [Bug #110707] does not compile under BSDI (PR#57) Message-ID: <200008062139.OAA01284@delerium.i.sourceforge.net> Bug #110707, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: does not compile under BSDI (PR#57) Details: Jitterbug-Id: 57 Submitted-By: jital@knoggin.com Date: Fri, 20 Aug 1999 04:18:04 -0400 (EDT) Version: py152 OS: BSDI IServer seems to think it is a NeXT arch or something $ ./configure --prefix=/usr/home/knoggin/usr/local/ --exec-prefix=/usr/home/knoggin/usr/local/ creating cache ./config.cache checking MACHDEP... bsdos3 checking CCC... checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... gcc -D_HAVE_BSDI -E checking for AIX... no checking for minix/config.h... no checking whether gcc -D_HAVE_BSDI accepts -OPT:Olimit=0... no checking whether gcc -D_HAVE_BSDI accepts -Olimit 1500... no checking for C preprocessor type... ansi checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... yes checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... no checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... no checking for sys/file.h... yes checking for sys/lock.h... yes checking for sys/param.h... yes checking for sys/select.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 4 checking size of void *... 4 checking for long long support... yes checking size of long long... 8 checking size of off_t... 8 checking whether to enable large file support... yes checking for --with-next-framework... no checking for --with-dyld... required for framework build checking SO... .so checking LDSHARED... ld checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for t_open in -lnsl... no checking for socket in -lsocket... no checking for socket in -lnet... no checking for --with-libs... no checking for --with(out)-readline... not specified. checking for --with-dec-threads... no checking for --with-threads... no checking for --with-thread... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for alarm... yes checking for chown... yes checking for clock... yes checking for dlopen... yes checking for execv... yes checking for flock... yes checking for fork... yes checking for fsync... yes checking for fdatasync... no checking for ftime... no checking for ftruncate... yes checking for getpeername... yes checking for getpgrp... yes checking for getpid... yes checking for getpwent... yes checking for gettimeofday... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for nice... yes checking for pause... yes checking for plock... no checking for pthread_init... yes checking for putenv... yes checking for readlink... yes checking for select... yes checking for setgid... yes checking for setlocale... yes checking for setuid... yes checking for setsid... yes checking for setpgid... yes checking for setpgrp... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... no checking for strftime... yes checking for strptime... no checking for symlink... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for timegm... no checking for times... yes checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for fseek64... no checking for fseeko... no checking for fstatvfs... no checking for ftell64... no checking for ftello... no checking for statvfs... no checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... (cached) yes checking for setpgrp... (cached) yes checking for gettimeofday... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... yes checking for time.h that defines altzone... no checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... no checking for gethostbyname... yes checking for __fpu_control in -lieee... no checking for --with-fpectl... checking for --with-libm=STRING... default LIBM="- lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for hypot... (cached) yes checking for genuine getopt... yes checking what malloc(0) returns... nonnull updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.thread creating config.h pcvendor:~/usr/local/src/Python-1.5.2 $ make (cd Modules; make -f Makefile.pre Makefile) cp ./Setup.in Setup echo "# Edit this file for local setup changes" >Setup.local rm -f ../libpython1.5.a /bin/sh ./makesetup Setup.thread Setup.local Setup making Makefile in subdirectory . `Makefile' is up to date. making Makefile in subdirectory Parser `Makefile' is up to date. making Makefile in subdirectory Objects `Makefile' is up to date. making Makefile in subdirectory Python `Makefile' is up to date. making Makefile in subdirectory Modules `Makefile' is up to date. (rm -f Modules/hassignal; cd Modules; make hassignal) rm -f hassignal for i in regexmodule.o regexpr.o pcremodule.o pypcre.o posixmodule.o signalmo dule.o arraymodule.o cmathmodule.o mathmodule.o stropmodule.o structmodule. o timemodule.o operator.o fcntlmodule.o pwdmodule.o grpmodule.o selectmodu le.o socketmodule.o errnomodule.o md5module.o md5c.o shamodule.o rotormodul e.o newmodule.o binascii.o parsermodule.o cStringIO.o cPickle.o config.o ge tpath.o main.o getbuildinfo.o; do if test "$i" = "signalmodule.o"; then echo y es >hassignal; break; fi; done cd Parser ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local /" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c acceler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar1.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listnode.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c node.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parser.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c parsetok.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tokenizer.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bitset.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c metagrammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c firstsets.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c grammar.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c pgen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c printgrammar.c gcc -D_HAVE_BSDI -g -O2 pgenmain.o acceler.o grammar1.o listnode.o node.o parse r.o parsetok.o tokenizer.o bitset.o metagrammar.o firstsets.o grammar.o pgen.o printgrammar.o -ldl -o pgen gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c myreadline.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intrcheck.c cd Objects ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c abstract.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bufferobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c classobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c cobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c complexobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c fileobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c floatobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frameobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c funcobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c intobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c listobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c longobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c dictobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c methodobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c moduleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c object.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c rangeobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c sliceobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c stringobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c tupleobject.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c typeobject.c cd Python ; make OPT="-g -O2" VERSION="1.5" prefix="/usr/home/knoggin/usr/local/" exec_prefix="/usr/home/knoggin/usr/local/" all gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c bltinmodule.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ceval.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c compile.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c errors.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozen.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c frozenmain.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getargs.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcompiler.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getcopyright.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getmtime.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -DPLATFORM='"bsdos3"' ./getplatform.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c getversion.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c graminit.c gcc -D_HAVE_BSDI -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c import.c gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c ./importdl.c:269: mach-o/dyld.h: No such file or directory *** Error code 1 Stop. *** Error code 1 Stop. ==================================================================== Audit trail: Mon Aug 30 12:40:26 1999 guido changed notes Mon Aug 30 12:40:26 1999 guido moved from incoming to irreproducible Tue Oct 19 23:20:49 1999 guido sent reply 1 Tue Oct 19 23:21:36 1999 guido changed notes Tue Oct 19 23:21:36 1999 guido moved from irreproducible to open Tue Oct 19 23:30:25 1999 guido changed notes Tue Oct 19 23:30:25 1999 guido moved from open to platformbug Follow-Ups: Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: does not compile under BSDI (PR#57) Date: Tue Oct 19 23:20:49 1999 This same bug was reported by someone else for the same platform. We arrived at the work-around of deleting the line #define WITH_DYLD from the config.h generated by the configure script. If you are still experiencing problems building Python, please try this. --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] does not compile under BSDI (PR#57) Date: Fri, 20 Aug 1999 07:57:10 -0400 > Full_Name: John Ital > Version: py152 > OS: BSDI IServer > > seems to think it is a NeXT arch or something > [...] > gcc -D_HAVE_BSDI -c -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -I/ ./importdl.c > ./importdl.c:269: mach-o/dyld.h: No such file or directory > *** Error code 1 Very strange. I've never seen this before. It appears that somehow USE_DYLD is defined at that point, which can only happen if WITH_DYLD is defined, which can only happen if you specify --with-next-framework or --with-dyld on the configure command line, which you didn't. Perhaps you have a buggy preprocessor that is confused by the tangle of #ifdefs in importdl.c? I don't know how to help you; I know Python has been built successfully on bsdos3 before, so I'm guessing it's something in your setup, not a Python bug. If you need more help, please ask a newsgroup -- either comp.lang.python or a BSD specific one. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: Work-around: if you delete #define WITH_DYLD from config.h, the build succeeds. ------------------------------------------------------- Date: 2000-Aug-03 09:00 By: twouters Comment: For the record, I cannot reproduce this on the BSDI 3.1 systems we still have lying around. It *might* have been specific to BSDI 3.0, which we no longer have (for various reasons, like y2k bugs ;) and I've heard similar (but not the same) reports about BSD/OS running under a 'virtual' machine. However, I've never seen or heard about those 'virtual' BSD/OSes, other than in that c.l.py posting. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110707&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:41:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:41:25 -0700 Subject: [Python-bugs-list] [Bug #110859] Environment dependency in re parser (PR#290) Message-ID: <200008062141.OAA01310@delerium.i.sourceforge.net> Bug #110859, was updated on 2000-Aug-01 14:38 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Not a Bug Priority: 3 Summary: Environment dependency in re parser (PR#290) Details: Jitterbug-Id: 290 Submitted-By: nmm1@cam.ac.uk Date: Wed, 12 Apr 2000 07:44:54 -0400 (EDT) Version: 1.5.2 OS: Irix 6.5 The following code works perfectly when used interactively: from re import match if match(r'"([^\"]|\?""|\\?)*"','"abc"') : print "Hello" When run non-interactively (e.g. 'python junk.py'), it fails: File "junk.py", line 3, in ? if match(r'"([^\"]|\?""|\\?)*"','"abc"') : File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match return _cachecompile(pattern, flags).match(string) File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in _cachecompile value = compile(pattern, flags) File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('operand of unlimited repeat could match the empty string', 17) ==================================================================== Audit trail: Tue Jul 11 08:29:16 2000 guido moved from incoming to open Thu Jul 13 20:37:02 2000 fdrake changed notes Thu Jul 13 20:37:02 2000 fdrake moved from open to irreproducible Follow-Ups: Date: 2000-Aug-01 14:38 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] Environment dependency in re parser (PR#290) Date: Wed, 12 Apr 2000 22:30:46 -0400 > Full_Name: Nick Maclaren > Version: 1.5.2 > OS: Irix 6.5 > Submission from: posh.mcc.wwwcache.ja.net (194.83.240.29) > > > The following code works perfectly when used interactively: > > from re import match > > if match(r'"([^\"]|\?""|\\?)*"','"abc"') : > print "Hello" > > When run non-interactively (e.g. 'python junk.py'), it fails: > > File "junk.py", line 3, in ? > if match(r'"([^\"]|\?""|\\?)*"','"abc"') : > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 40, in match > return _cachecompile(pattern, flags).match(string) > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 33, in > _cachecompile > value = compile(pattern, flags) > File "/usr/local/Python-1.5.2/lib/python1.5/re.py", line 79, in compile > code=pcre_compile(pattern, flags, groupindex) > pcre.error: ('operand of unlimited repeat could match the empty > string', 17) It yields the same error for me whether run interactively or from file, under the released 1.5.2 for Windows, here run from a DOS box: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from re import match >>> if match(r'"([^\"]|\?""|\\?)*"','"abc"') : ... print "Hello" ... Traceback (innermost last): File "", line 1, in ? File "D:\Python\Lib\re.py", line 40, in match return _cachecompile(pattern, flags).match(string) File "D:\Python\Lib\re.py", line 33, in _cachecompile value = compile(pattern, flags) File "D:\Python\Lib\re.py", line 79, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('operand of unlimited repeat could match the empty string', 17) >>> The error msg is appropriate, since the third branch of the alternative matches 0 or 1 backslashes, so the alternative as a whole can match the empty string -- the error msg means exactly what it says. This is functioning correctly as designed. Perhaps you're using an interactive shell with a filter (readline?) that's chewing up some of the backslashes itself? ------------------------------------------------------- Date: 2000-Aug-01 14:38 By: none Comment: Something from outside of Python appears to causing this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110859&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:41:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:41:48 -0700 Subject: [Python-bugs-list] [Bug #110676] fd.readlines() hangs (via popen3) (PR#385) Message-ID: <200008062141.OAA01320@delerium.i.sourceforge.net> Bug #110676, was updated on 2000-Jul-31 14:13 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: fd.readlines() hangs (via popen3) (PR#385) Details: Jitterbug-Id: 385 Submitted-By: aron@gweep.net Date: Tue, 4 Jul 2000 19:07:55 -0400 (EDT) Version: 1.5.2 OS: Red Hat Linux 6.1 (2.1.12-20) The following scripts cause a hang at the denoted line. To execute this code, copy the first bit to master.py and the second to slave.py (both should be in the same directory). Then, "cd" to that directory and "python master.py". Manually killing the program is necessary. This script has also been tested on a Solaris 5.7 box and worked. ---master.py--- import popen2 r,w,e = popen2.popen3 ( 'python slave.py' ) r.readlines() # Hangs here e.readlines() r.close() e.close() w.close() ---end--- ---slave.py--- import sys e = sys.stderr.write w = sys.stdout.write e(400*'this is a test\n') w(400*'this is another test\n') ---end--- ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110676&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:42:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:42:36 -0700 Subject: [Python-bugs-list] [Bug #110835] Find out size of primitive object (PR#214) Message-ID: <200008062142.OAA01332@delerium.i.sourceforge.net> Bug #110835, was updated on 2000-Aug-01 14:13 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: Find out size of primitive object (PR#214) Details: Jitterbug-Id: 214 Submitted-By: loewis@informatik.hu-berlin.de Date: Fri, 25 Feb 2000 14:28:33 -0500 (EST) Version: 1.5.2 OS: Solaris 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. ==================================================================== Audit trail: Tue Mar 07 14:42:18 2000 guido changed notes Tue Mar 07 14:42:18 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:14 By: none Comment: Interesting idea. Is this what we need? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110835&group_id=5470 From noreply@sourceforge.net Sun Aug 6 22:43:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 14:43:01 -0700 Subject: [Python-bugs-list] [Bug #110642] freeze with "-s service" and "-m" (PR#315) Message-ID: <200008062143.OAA01352@delerium.i.sourceforge.net> Bug #110642, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: freeze with "-s service" and "-m" (PR#315) Details: Jitterbug-Id: 315 Submitted-By: tdickenson@geminidataloggers.com Date: Fri, 5 May 2000 05:50:37 -0400 (EDT) Version: 1.5.2 OS: Windows There is a problem with combining two different options to freeze. Those options are: 1. "-s service" indicating that the frozen program is a windows service. one effect of this is that the myscript.py file on the freeze command line should be available for import, not as __main__ 2. "-m" indicating that extra modules are to be included in the freeze. The relevant block of code is at line 335... # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: if modargs: mf.import_hook(scriptfile) else: mf.load_file(scriptfile) For a service, the outer 'else' block is entered. If -m is not specified then the inner 'else' block is entered. mf.load_file assumes its parameter is a filename (to be imported from), an everything is happy. If -m is specified then the inner 'if' block is entered. mf.import_hook assumes its parameter is a module to imported. This fails because "myscript.py" is not a module name, and can not be imported. I think this block of code was naively copy/pasted from the block above it (where it correctly implements the -m option), and never tested with the -m option. This block (starting line 335) should be replaced with # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: mf.load_file(scriptfile) I have tested this patch on windows, freezing service and non-service scripts, both with and without -m ==================================================================== Audit trail: Mon May 22 17:28:43 2000 guido changed notes Mon May 22 17:28:43 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:10 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] freeze with "-s service" and "-m" (PR#315) Date: Fri, 5 May 2000 23:19:14 +1000 > I think this block of code was naively copy/pasted from the > block above it Quite likely! > This block (starting line 335) should be replaced with ... If you submit a patch to this effect (to the patches address), I would be happy to bless it (and given that the service code is mine, I guess that would be all that is needed...) Thanks, Mark. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110642&group_id=5470 From noreply@sourceforge.net Sun Aug 6 23:55:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 6 Aug 2000 15:55:09 -0700 Subject: [Python-bugs-list] [Bug #110673] os.abspatth() error due to win32api.GetFullPathName (PR#380) Message-ID: <200008062255.PAA11182@bush.i.sourceforge.net> Bug #110673, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: os.abspatth() error due to win32api.GetFullPathName (PR#380) Details: Jitterbug-Id: 380 Submitted-By: 2jerry@writeme.com Date: Mon, 3 Jul 2000 17:14:02 -0400 (EDT) Version: 1.5.2 (win32api build 129) OS: pc win98 next to code: full_path_lst = map(os.path.abspath, sys.path) according to that sys.path include the source directory at the first place of sys.path. I noticed that if I call the module in its own directory (python -i module.py) the first item of sys.path is ''. That all ok: abspath function in os module call getcwd() function if path is Null. ... good day for UNIX like men (as me :)) ... but in NT or WIN 98 workstation: os.path.abspath call :win32api.GetFullPathName(path) in ntpath module and win32api.GetFullPathName('') return '' and not current directory. Maybe is it a functionality .. but is os-depend functionality available for a longtime ? Jerome.vacher alias Jerry the foolish dracomorpheus. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 16:19:30 +1000 Can anyone else here confirm that: a) os.abspath('') on Linux does indeed return the CWD. b) It is supposed to :-) If confirmed, this would be a bug in ntpath.py. It catches win32api exceptions, and returns the input name in that case. This would be triggered by: >>> win32api.GetFullPathName('') Traceback (most recent call last): File "", line 1, in ? pywintypes.api_error: (127, 'GetFullPathName', 'The specified procedure could not be found.') Is this indeed something we should fix? Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > 2jerry@writeme.com > Sent: Tuesday, 4 July 2000 7:14 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) > (PR#380) > > > Full_Name: Jerome VACHER > Version: 1.5.2 (win32api build 129) > OS: pc win98 > Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55) > > > next to code: > full_path_lst = map(os.path.abspath, sys.path) > > according to that sys.path include the source directory at the > first place of > sys.path. > > I noticed that if I call the module in its own directory (python > -i module.py) > the first item of sys.path is ''. > That all ok: abspath function in os module call getcwd() > function if path is > Null. > ... > good day for UNIX like men (as me :)) > ... > but in NT or WIN 98 workstation: > os.path.abspath call :win32api.GetFullPathName(path) in ntpath module > and > win32api.GetFullPathName('') return '' and not current directory. > > Maybe is it a functionality .. but is os-depend functionality > available for a > longtime ? > > Jerome.vacher alias Jerry the foolish dracomorpheus. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: "Fred L. Drake, Jr." Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 13:34:24 -0400 (EDT) Mark Hammond writes: > Can anyone else here confirm that: > > a) os.abspath('') on Linux does indeed return the CWD. Yes, that's right. > b) It is supposed to :-) I think that's the right thing to do. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member ------------------------------------------------------- Date: 2000-Aug-06 13:56 By: twouters Comment: Possibly already fixed, or at least Mark has looked at it :) ------------------------------------------------------- Date: 2000-Aug-06 15:55 By: mhammond Comment: This is not a bug in win32api.GetFullPathName(), but rather the use of GetFullPathName() to implement os.abspath(). Bug summary changed accordingly. Confirmed as a bug, and I will fix it! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110673&group_id=5470 From noreply@sourceforge.net Mon Aug 7 12:36:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 04:36:19 -0700 Subject: [Python-bugs-list] [Bug #110645] XMLLIB, JPython and re (PR#328) Message-ID: <200008071136.EAA26837@delerium.i.sourceforge.net> Bug #110645, was updated on 2000-Jul-31 14:10 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: XMLLIB, JPython and re (PR#328) Details: Jitterbug-Id: 328 Submitted-By: peter@verecomm.com Date: Mon, 15 May 2000 15:21:33 -0400 (EDT) Version: 1.52 OS: Linux There's a problem with the xmllib module when used with JPython. Specifically, the JPython re module has trouble with the () characters in strings passed into re.compile. Until the JPython folks fix the re module, I'd like to ask that the xmllib module be modified to escape the () characters. Here's the output from diff: $ diff xmllib.py /usr/lib/python1.5/ 29c29 < '(?P'+_QStr+'|[-a-zA-Z0-9.:+*%?!\(\)_#=~]+))?') --- > '(?P'+_QStr+'|[-a-zA-Z0-9.:+*%?!()_#=~]+))?') 45,46c45,46 < _PublicLiteral = '(?P<%s>"[-\'\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ < "'[-\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" --- > _PublicLiteral = '(?P<%s>"[-\'()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ > "'[-()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" Thanks! ==================================================================== Audit trail: Mon May 22 17:29:00 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110645&group_id=5470 From noreply@sourceforge.net Mon Aug 7 13:07:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 05:07:42 -0700 Subject: [Python-bugs-list] [Bug #110664] PRIVATE: Bug in re module (PR#36) Message-ID: <200008071207.FAA27885@delerium.i.sourceforge.net> Bug #110664, was updated on 2000-Jul-31 14:11 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PRIVATE: Bug in re module (PR#36) Details: Jitterbug-Id: 36 Submitted-By: chenna@embl-heidelberg.de Date: Fri, 23 Jul 1999 06:51:43 -0400 (EDT) Version: 1.5.1 OS: OSF1 Hello I get Stack overflow: pid 14731, proc emparse1.py, addr 0x11fdfffd8, pc 0x120068cd8 Segmentation fault when I run the following. The problem is re module unable to search for the pattern that is too large, but this is a requirement for my application in biology. I enclose the source code with this. Please email me the solution as soon as possible Thanks Ramu ___________________________ #!/usr/pub/bin/python1.5 # # # # (C) Chenna Ramu, EMBL, Heidelberg, Germany # # parser for biological databases # import string import sys import re parserDict = { 'id' : r'((^ID [^\n]+\n)+)' , 'ac' : r'((^AC [^\n]+\n)+)' , 'dt' : r'((^DT [^\n]+\n)+)' , 'de' : r'((^DE [^\n]+\n)+)' , 'gn' : r'((^GN [^\n]+\n)+)' , 'os' : r'((^OS [^\n]+\n)+)' , 'oc' : r'((^OC [^\n]+\n)+)' , 'ref' : r'((' r'(^RN [^\n]+\n)' r'((^RP [^\n]+\n)+)' r'((^RX [^\n]+\n)?)' r'((^RA [^\n]+\n)+)' r'((^RT [^\n]+\n)*)' r'((^RL [^\n]+\n)+)' r')+)', 'cc' : r'((^CC [^\n]+\n)+)' , 'dr' : r'((^DR [^\n]+\n)+)' , 'kw' : r'((^KW [^\n]+\n)+)' , 'ft' : r'((^FT [^\n]+\n)+)' , 'sq' : r'(^SQ [^\n]+\n)' \ r'((^ [^\n]+\n)+)' } _hrefLink = {'embl':['%s','^DR ([^;]+)']} #should be like this hrefLink = {'EMBL':"%s", 'MIM':"%s"} em_rep = r'(^DR )(?P[^;]+); (?P[^;]+)' class embl: def __init__(self,parserDict={}): self.parserDict = {} self.reDict = {} #keep the compiled re's self.fields = [] if parserDict: self.Init(parserDict) def Init(self,parserDict): self.parserDict = parserDict self.fields = parserDict.keys() for j in self.fields: setattr(self, j, None) self.reDict[j] = re.compile(parserDict[j],re.MULTILINE) def Parse(self,str): if not self.parserDict: print "No parser specified" return for k,v in parserDict.items(): ## tmp = re.compile(v,re.MULTILINE) # move this to __init__ tmp = self.reDict[k] mat = tmp.search(str) if mat: setattr(self, k, mat.group() ) def Field(self,name): try: return getattr(self,name) except AttributeError: return None def PrintFields(self): flds = self.fields for j in flds: print "==> ",j print getattr(self,j) def ReParse(self,str,retToken,pat): """ str:string to parse, retToken:return token, pat:parser """ _p = re.compile(pat) m = _p.search(str) if m: return m.group(retToken) else: return None def Href(match): """ Replaces the hrefs """ dbase = match.group('dbase') id = match.group('id') try: defi = hrefLink[dbase] except KeyError: defi = None if defi: tmp = match.group(1) + dbase + '; '+defi %(dbase,id,id) else: tmp = match.group(1)+ dbase + '; ' + id return tmp def test(fileName): sys.path.insert(0,'/home/chenna/py') ## from seqFormat import * e = embl(parserDict) # f = open('acha_mouse.dat','r') f = open(fileName,'r') a = f.readlines() f.close() a = string.join(a,'') e.Parse(a) e.PrintFields() import string print ' the fields are ',e.fields ## seq = string.split(e.sq,';')[-1] ## s = Seq(seq,'test') ## print 'check===>',s.seq ## s.SeqPrint('swiss') seqLen = e.ReParse(e.sq[0:50],'seqLen',r'^SQ [^ ]+ *(?P(\d+))') print e.sq print "length of the sequence ",seqLen print e.ref dr = e.dr print dr p = re.compile(em_rep,re.M) dr = p.sub(Href,dr) print dr print e.Field('id') print e.Field('dr') print e.Field('mm') return def test1(dumm=None): tmp = ['SQ Sequence 1041931 BP; 8972 A; 5950 C; 6264 G; 8224 T; 0 other;\n'] for j in range(1,17365): t = ' ' + 'tcagtcagtg ' * 6 + '\n' tmp.append(t) a = string.join(tmp) e = embl(parserDict) e.Parse(a) e.PrintFields() if __name__ == '__main__': try: test1(sys.argv[1]) except: test1() ==================================================================== Audit trail: Sat Jul 24 16:53:53 1999 guido changed notes Sat Jul 24 16:53:53 1999 guido moved from incoming to open Sat Jul 24 17:04:17 1999 guido changed notes Follow-Ups: Date: 2000-Aug-06 13:53 By: twouters Comment: Fair chance this is already fixed, either in 1.5.2 remodule, or in the new 'sre' by Fredrik. Maybe /F can say something useful here. ------------------------------------------------------- Date: 2000-Aug-07 05:07 By: effbot Comment: It works fine under SRE, but bombs under PRE using a recent 2.0 build (tested on Windows). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110664&group_id=5470 From noreply@sourceforge.net Tue Aug 8 00:29:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 7 Aug 2000 16:29:03 -0700 Subject: [Python-bugs-list] [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 Message-ID: <200008072329.QAA19294@delerium.i.sourceforge.net> Bug #111319, was updated on 2000-Aug-07 16:29 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Autoconfig breakdown with gnu libc-2.1.3 Details: Pythons config.h (which is included via Python.h) defines this on redhat-6.2: /* Define to `int' if doesn't define. */ #define socklen_t int The trouble is that gnu libc-2.1.3 does not define socklen_t in . It defines it in : /* Type for length arguments in socket calls. */ typedef unsigned int socklen_t; In this case, pythons definition causes a compilation failure which can be demonstrated by the following simple program: #include #include int main() { return 0; } My guess is that the autoconfig macros need to be updated to search as well. Mike Romberg (romberg@fsl.noaa.gov) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111319&group_id=5470 From noreply@sourceforge.net Tue Aug 8 12:22:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 04:22:50 -0700 Subject: [Python-bugs-list] [Bug #110645] XMLLIB, JPython and re (PR#328) Message-ID: <200008081122.EAA16392@bush.i.sourceforge.net> Bug #110645, was updated on 2000-Jul-31 14:10 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: XMLLIB, JPython and re (PR#328) Details: Jitterbug-Id: 328 Submitted-By: peter@verecomm.com Date: Mon, 15 May 2000 15:21:33 -0400 (EDT) Version: 1.52 OS: Linux There's a problem with the xmllib module when used with JPython. Specifically, the JPython re module has trouble with the () characters in strings passed into re.compile. Until the JPython folks fix the re module, I'd like to ask that the xmllib module be modified to escape the () characters. Here's the output from diff: $ diff xmllib.py /usr/lib/python1.5/ 29c29 < '(?P'+_QStr+'|[-a-zA-Z0-9.:+*%?!\(\)_#=~]+))?') --- > '(?P'+_QStr+'|[-a-zA-Z0-9.:+*%?!()_#=~]+))?') 45,46c45,46 < _PublicLiteral = '(?P<%s>"[-\'\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ < "'[-\(\)+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" --- > _PublicLiteral = '(?P<%s>"[-\'()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*"|' \ > "'[-()+,./:=?;!*#@$_%% \n\ra-zA-Z0-9]*')" Thanks! ==================================================================== Audit trail: Mon May 22 17:29:00 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-08 04:22 By: sjoerd Comment: This bug was fixed in revision 1.18. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110645&group_id=5470 From noreply@sourceforge.net Tue Aug 8 19:26:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 8 Aug 2000 11:26:28 -0700 Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate Message-ID: <200008081826.LAA23686@delerium.i.sourceforge.net> Bug #111403, was updated on 2000-Aug-08 11:26 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: 1.6b1 dumps core dereferencing a NULL tstate Details: This is from an embeded python. I've not yet been able to reproduce this with a small example. But perhaps this stacktrace will be of some help. The problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back. This pointer is dereferenced in PyFrame_New() later on which causes the core dump. The documentation seems to say that PyThreadState_GET() should never return NULL. So, there must be a bug in there somewhere. Here is the stack trace: #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 120 PyFrameObject *back = tstate->frame; (gdb) bt #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 #1 0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x925d2e8) at ceval.c:397 #2 0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0) at ceval.c:2521 #3 0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, kw=0x0) at ceval.c:2359 #4 0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0) at abstract.c:1370 #5 0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80) at DrawingArea.C:971 #6 0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027 #7 0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169 #8 0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1) at ./tclUnixNotfy.c:405 #9 0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444 #10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747 #11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0) at ./_tkinter.c:1794 #12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2396 #13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2361 #14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, defcount=1, owner=0x0) at ceval.c:1680 #15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, defcount=0, owner=0x92c6238) at ceval.c:1579 #16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038) at ceval.c:290 #19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885 #20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870 #21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847 #22 0x867ce4e in PyRun_SimpleString ( command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589 #23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248 #24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30 Mike Romberg (romberg@fsl.noaa.gov) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:15:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:15:43 -0700 Subject: [Python-bugs-list] [Bug #110603] Tkinter winfo_visualsavailable method (PR#156) Message-ID: <200008090915.CAA31163@bush.i.sourceforge.net> Bug #110603, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Tkinter winfo_visualsavailable method (PR#156) Details: Jitterbug-Id: 156 Submitted-By: piers@cs.su.oz.au Date: Thu, 9 Dec 1999 17:09:50 -0500 (EST) Version: 1.5.2 OS: Solaris/Linux/win95 The Tkinter winfo_visualsavailable method fails if there is only one visual available, as the code assumes a list is returned, when in fact Tcl/Tk returns a string in the form '{truecolor 24}' ==================================================================== Audit trail: Tue Dec 14 17:15:16 1999 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110603&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:16:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:16:20 -0700 Subject: [Python-bugs-list] [Bug #110605] Tkinter inconsistency (missing methods) (PR#161) Message-ID: <200008090916.CAA31175@bush.i.sourceforge.net> Bug #110605, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Tkinter inconsistency (missing methods) (PR#161) Details: Jitterbug-Id: 161 Submitted-By: Guido van Rossum Date: Thu, 16 Dec 1999 15:49:26 -0500 Version: None OS: None ------- Forwarded Message Date: Thu, 16 Dec 1999 13:48:20 +1100 From: Jonathan Giddy To: guido@python.org Subject: Tkinter inconsistency (missing methods) In Tkinter.py, most scrollable widgets support [xy]view_moveto and [xy]view_scroll, in addition to a basic [xy]view method. However, the Text widget is missing these additional methods. Thanks, Jon. ------- End of Forwarded Message ==================================================================== Audit trail: Wed Jan 12 18:30:41 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110605&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:17:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:17:13 -0700 Subject: [Python-bugs-list] [Bug #110671] Tk-based widgets misbehave with dead keys (PR#376) Message-ID: <200008090917.CAA31202@bush.i.sourceforge.net> Bug #110671, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: Tk-based widgets misbehave with dead keys (PR#376) Details: Jitterbug-Id: 376 Submitted-By: fstajano@uk.research.att.com Date: Thu, 29 Jun 2000 12:49:44 -0400 (EDT) Version: 1.6a2 OS: Windows 98 and 2000 This is a problem of the underlying widget set and not of Idle itself, but Idle is where I encountered it (I normally use Emacs), and since Python 1.6 is the unicode version I suppose it's worth looking into anyway (what good is it to have international chars if you can't input them ;-)). If, on Windows, you use a keyboard layout with dead keys, such as "United States - International", then Idle does not respond properly to dead keys. In particular, double-quote comes out as single-quote; single-quote comes out as space; and accented characters come out as non-accented. The lack of support for the accented chars is a minor nuisance, but the problems with quotes are a major one -- Idle is almost unusable under these circumstances. Not as bad as Pythonwin, though, which just crashes. [As you will know, the US-I keyboard defines things like single-quote and double-quote as dead keys so that one can produce accents and umlauts respectively by following the dead key with the appropriate vowel. To produce a double-quote on its own, you have to press double-quote followed by space.] ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110671&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:18:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:18:08 -0700 Subject: [Python-bugs-list] [Bug #110677] PRIVATE: various minor Tkinter things (PR#388) Message-ID: <200008090918.CAA31221@bush.i.sourceforge.net> Bug #110677, was updated on 2000-Jul-31 14:13 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PRIVATE: various minor Tkinter things (PR#388) Details: Jitterbug-Id: 388 Submitted-By: markus.oberhumer@jk.uni-linz.ac.at Date: Wed, 5 Jul 2000 09:38:11 -0400 (EDT) Version: python CVS OS: all Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter. Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll Canvas.CanvasItem & Canvas.Group: - bind lacks an optional "add" param - unbind lacks an optional "funcid" param - tkraise/lower should call self.canvas.tag_XXXX - bbox() return value is inconsistent with Canvas.bbox() ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:21:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:21:00 -0700 Subject: [Python-bugs-list] [Bug #110823] Tkinter missing button state symbols (PR#132) Message-ID: <200008090921.CAA31377@bush.i.sourceforge.net> Bug #110823, was updated on 2000-Aug-01 14:10 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: Tkinter missing button state symbols (PR#132) Details: Jitterbug-Id: 132 Submitted-By: aa8vb@yahoo.com Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 I have: picture.bind( "" , click_cb ) picture.bind( "", click_cb ) In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. Where are the Tkinter constants for these? Or how should one distinguish between a press and release in a callback? (I want to avoid having a separate callback for each type of event.) ==================================================================== Audit trail: Thu Nov 18 10:42:46 1999 guido changed notes Thu Nov 18 10:42:46 1999 guido moved from incoming to notabug Thu Nov 18 14:07:59 1999 guido changed notes Thu Nov 18 14:07:59 1999 guido moved from notabug to request Follow-Ups: Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 10:41:31 -0500 > Full_Name: Randall Hopper > Version: 1.5.2 > OS: IRIX 6.5 > Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) > > > I have: > > picture.bind( "" , click_cb ) > picture.bind( "", click_cb ) > > In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. > > Where are the Tkinter constants for these? Or how should one distinguish > between a press and release in a callback? > > (I want to avoid having a separate callback for each type of event.) This is not a question for the bugs list. Write to help@python.org or use the newsgroup for help. I don't know offhand what the answer is to your question; I suspect that the answer is in the Tcl/Tk man page for the bind command though. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: From: Randall Hopper Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 14:04:13 -0500 Guido van Rossum: |> Full_Name: Randall Hopper |> Version: 1.5.2 |> OS: IRIX 6.5 |> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) |> |> |> I have: |> |> picture.bind( "" , click_cb ) |> picture.bind( "", click_cb ) |> |> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. |> |> Where are the Tkinter constants for these? Or how should one distinguish |> between a press and release in a callback? |> |> (I want to avoid having a separate callback for each type of event.) | |This is not a question for the bugs list. | |Write to help@python.org or use the newsgroup for help. I don't know |offhand what the answer is to your question; I suspect that the answer |is in the Tcl/Tk man page for the bind command though. My fault. I should have rephrased the question into a statement. Tkinter does not provide symbol defines for event.state values (%s keyword in Tcl). Tcl doesn't either, but it would be useful if Tkinter did. This is a small enhancement request rather than a hard bug, but I thought the submission form was for probably applicable for both. Thanks, Randall ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 14:05:57 -0500 Yes, requests are okay. Sorry for the confusion. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: Should add a symbol as he suggests. ------------------------------------------------------- Date: 2000-Aug-09 02:21 By: effbot Comment: IIRC, these constants are platform (X library) dependent (they have to be exported from _tkinter.c, not Tkconstants.py). I'll investigate. Feel free to assign the bug to me if you like. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110823&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:27:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:27:41 -0700 Subject: [Python-bugs-list] [Bug #110866] re group self-reference weird behavior (PR#2) Message-ID: <200008090927.CAA31600@bush.i.sourceforge.net> Bug #110866, was updated on 2000-Aug-01 14:41 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: re group self-reference weird behavior (PR#2) Details: Jitterbug-Id: 2 Submitted-By: guido@python.org Date: Mon, 12 Jul 1999 15:03:24 -0400 (EDT) Version: 1.5.2 OS: Unix, Windows Try the following: import re re.search("((.)\\1+)","a") This isn't proper syntax (you shouldn't reference a group inside itself), but it seems to hang -- in fact it takes several minutes to execute. Possibly it runs out of some resource on its path to infinite recursion and then backtracks? ==================================================================== Audit trail: Mon Jul 12 15:33:07 1999 guido moved from incoming to open Mon Jul 12 19:02:35 1999 guido changed notes Thu Jul 13 20:28:48 2000 fdrake changed notes Thu Jul 13 20:28:48 2000 fdrake changed notification Thu Jul 13 20:28:48 2000 fdrake moved from open to 3rdpartybug Follow-Ups: Date: 2000-Aug-01 14:41 By: none Comment: AMK: pcre bug that's been fixed in more recent releases, but that's no longer relevant with SRE in the picture. ------------------------------------------------------- Date: 2000-Aug-09 02:27 By: effbot Comment: on the other hand, SRE says "nothing to repeat" -- which isn't really what it should do. Looks like the width calculation messes up on GROUPREF's... I've reassigned it to myself! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110866&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:33:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:33:57 -0700 Subject: [Python-bugs-list] [Bug #110869] REs beginning with .* (PR#47) Message-ID: <200008090933.CAA31834@bush.i.sourceforge.net> Bug #110869, was updated on 2000-Aug-01 14:42 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: None Bug Group: 3rd Party Priority: 5 Summary: REs beginning with .* (PR#47) Details: Jitterbug-Id: 47 Submitted-By: nfakh@bom2.vsnl.net.in Date: Sun, 8 Aug 1999 11:42:13 -0400 (EDT) Version: 1.5.1, 1.5.2 OS: Linux (RedHat 5.2) Let p = ".*" + r , where r is a regular expression. Let s be any string such that re.search(r,s).group() does not contain any characters before the first newline character. Then re.search(p,s) seems to fail in all the examples that I've tried. Example: >>> r = "d" >>> s = "abc\nabd" >>> print re.search(".*" + r, s) None I woud have thought that re.search(".*" + r, s) should match 'abd'. ==================================================================== Audit trail: Tue Aug 10 17:45:54 1999 guido changed notes Tue Aug 10 17:45:54 1999 guido moved from incoming to open Thu Jul 13 20:33:39 2000 fdrake changed notes Thu Jul 13 20:33:39 2000 fdrake changed notification Thu Jul 13 20:33:39 2000 fdrake moved from open to 3rdpartybug Follow-Ups: Date: 2000-Aug-01 14:42 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] REs beginning with .* (PR#47) Date: Mon, 09 Aug 1999 10:25:54 -0400 I think you're right, especially since re.search("a.*d", "abc\nabd") correctly matches "abd". I've forwarded this to Andrew Kuchling who is maintaining the re module. --Guido van Rossum (home page: http://www.python.org/~guido/) > Let p = ".*" + r , where r is a regular expression. Let s be any string > such that re.search(r,s).group() does not contain any characters before > the first newline character. Then re.search(p,s) seems to fail in all > the examples that I've tried. > > Example: > >>> r = "d" > >>> s = "abc\nabd" > >>> print re.search(".*" + r, s) > None > > I woud have thought that re.search(".*" + r, s) should match 'abd'. ------------------------------------------------------- Date: 2000-Aug-01 14:42 By: none Comment: AMK says it's a misfired optimization (see string-sig archives). Fixed in a more recent pcre release, but no longer relevant with the coming of SRE in Python 2.0. ------------------------------------------------------- Date: 2000-Aug-09 02:33 By: effbot Comment: Works in SRE. I've added a test to the regression test suite, and closed this bug. (if we decide to fix more bugs in PCRE, just run the new regression suite on it...) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110869&group_id=5470 From noreply@sourceforge.net Wed Aug 9 10:35:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 02:35:18 -0700 Subject: [Python-bugs-list] [Bug #110924] exec unicodeobject doesn't work Message-ID: <200008090935.CAA31860@bush.i.sourceforge.net> Bug #110924, was updated on 2000-Aug-02 08:17 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: exec unicodeobject doesn't work Details: exec u"print 42" doesn't work. Follow-Ups: Date: 2000-Aug-09 02:35 By: effbot Comment: python doesn't support 16-bit source code -- so what exactly do you want exec to do? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470 From noreply@sourceforge.net Wed Aug 9 14:38:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 06:38:39 -0700 Subject: [Python-bugs-list] [Bug #111481] os.stat() doesn't return st_rdev Message-ID: <200008091338.GAA09318@bush.i.sourceforge.net> Bug #111481, was updated on 2000-Aug-09 06:38 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: os.stat() doesn't return st_rdev Details: The call os.stat() returns the fields st_mode, st_ino, st_nlink, st_uid, st_gid, st_size, st_atime, st_mtime st_ctime from "struct stat". To be able to explore device nodes on a linux system the field st_rdev needed as the major and minor device number is stored in this field. It would be nice if it could be added as an extra element in the tuple returned by os.stat, os.lstat etc. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111481&group_id=5470 From elcultural.com@python.org Wed Aug 9 15:21:57 2000 From: elcultural.com@python.org (elcultural.com@python.org) Date: Wed, 9 Aug 2000 10:21:57 -0400 (EDT) Subject: [Python-bugs-list] Actualidad Cultural (PR#427) Message-ID: <20000809142157.248061CD29@dinsdale.python.org> Actualidad Cultural <body> <table cellspacing="0" cellpadding="0" border="0"> <tr> <td width="10" height="7" valign="top"></td> <td height="28" colspan="2" rowspan="2" valign="middle"><img SRC="http://www.elcultural.com/correo/img/elcultural.jpg" height=13 width=123></td> <td width="78" height="7" valign="top"></td> <td width="5" height="7" valign="top"></td> <td width="9" height="7" valign="top"></td> <td width="6" height="7" valign="top"></td> <td width="150" height="7" valign="top"></td> <td width="9" height="7" valign="top"></td> <td width="9" height="7" valign="top"></td> <td width="173" height="7" valign="top"></td> </tr> <tr> <td width="10" height="21" valign="top"></td> <td width="78" height="21" valign="top"></td> <td width="5" height="21" valign="top"></td> <td width="9" height="21" valign="top"></td> <td width="6" height="21" valign="top"></td> <td width="150" height="21" valign="top"></td> <td width="9" height="21" valign="top"></td> <td width="9" height="21" valign="top"></td> <td width="173" height="652" rowspan="15" valign="top" bgcolor="#FFFFCC"> <center> <p><a href="http://www.elcultural.com"><img SRC="http://www.elcultural.com/correo/img/logo2.gif" BORDER=0 height=56 width=68></a></p> <p><b><font face="Arial,Helvetica"><font size=-2>Otros Titulares</font></font></b> </p> </center> <p align="left"><font size=-2><font face="Wingdings"> &nbsp;n <font face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/contenidos/webdelasemana/20000807.asp">Letra lia La revista en Internet para los escritores latinoamericanos</a></font></font></font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n <font face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/bflamenco/entrevistas03.htm">Antonio el Pipa: "Mi meta es morirme bailando"</a></font></font></font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n </font></font> <font size="1" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/contenidos/reportaje/230700/1.asp">De sur a sur: creadores africanos vinculados a España</a></font> <center> <p> <p> <p> <p> <p> <p> <p> <br> <table width="142" border="0"> <tr bgcolor="#CCCC99"> <td> <div align="center"><font size="1" face="Arial, Helvetica, sans-serif"><b><a href="http://www.elcultural.com/">EVENTOS RECOMENDADOS</a></b></font></div> </td> </tr> <tr bgcolor="#CCCC99"> <td height="2"> <div align="center"><font size="1" face="Arial, Helvetica, sans-serif"><b><a href="http://www.elcultural.com/contenidos/arquitec/20000720/default.asp">AR QUITECTURA</a></b></font></div> </td> </tr> <tr bgcolor="#CCCC99"> <td height="2"> <div align="center"><font face="Arial, Helvetica, sans-serif" size="1"><b><a href="../contenidos/webdelasemana/20000807.asp">WEB DE LA SEMANA</a></b></font></div> </td> </tr> </table> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/">Portada</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com">Noticias culturales</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/dinamica/index.html">Versi&oacute;n multimedia</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/criticas/default.asp">Cr&iacute;tica de eventos</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/resenas/cds/default.asp">Rese&ntilde;as de discos</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/resenas/libros/default.asp">Rese&ntilde;as de libros</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com">Cartelera de Andaluc&iacute;a</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/eva/index.html">Espacio Virtual de las Artes</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/andalucia/default.asp">Andaluc&iacute;a Cultural</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/entrevista/default.asp">Entrevist as</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/reportaje/default.asp">Reportajes </a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/evento/default.asp">Eventos</a></ font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/denominacion/default.asp">Denomin aci&oacute;n de Origen</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/tema/default.asp">Temas de Actualidad</a></font></font> </center> <img width="144" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> </tr> <tr> <td width="10" height="22" valign="top"></td> <td height="22" colspan="8" valign="top" bgcolor="#FFFFCC"> <table width="100%" border="0" mm_noconvert="TRUE"> <tr> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/cine.asp"><font color="#000099"><b>cine</b></font></a></font></td> <td><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/temas/arte.asp"><b><font color="#000099">arte</font></b></a></font></td> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/escena.asp"><font color="#000099"><b>escena</b></font></a></font></td> <td><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/temas/musica.asp"><font color="#000099"><b>m&uacute;sica</b></font></a></font></td> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/literatura.asp"><b><font color="#000099">literatura</font></b></a></font></td> </tr> </table></td> <td width="9" height="22" valign="top"></td> </tr> <tr> <td width="10" height="7" valign="top"></td> <td width="4" height="7" valign="top"></td> <td width="121" height="7" valign="top"></td> <td width="78" height="7" valign="top"></td> <td width="5" height="7" valign="top"></td> <td width="9" height="7" valign="top"></td> <td width="6" height="7" valign="top"></td> <td width="150" height="7" valign="top"></td> <td width="9" height="7" valign="top"></td> <td width="9" height="7" valign="top"></td> </tr> <tr> <td width="10" height="26" valign="top"></td> <td height="26" colspan="8" valign="top"><b><font face="Arial,Helvetica" size="4">Arte entre rejas.</font></b></td> <td width="9" height="26" valign="top"></td> </tr> <tr> <td width="10" height="8" valign="top"></td> <td width="4" height="8" valign="top"></td> <td width="121" height="8" valign="top"></td> <td width="78" height="8" valign="top"></td> <td width="5" height="8" valign="top"></td> <td width="9" height="8" valign="top"></td> <td width="6" height="8" valign="top"></td> <td width="150" height="96" rowspan="2" valign="top"> <img src="http://www.elcultural.com/correo/img/libportada.jpg" width="150" height="79"></td> <td width="9" height="8" valign="top"></td> <td width="9" height="8" valign="top"></td> </tr> <tr> <td width="10" height="76" valign="top"></td> <td width="4" height="76" valign="top"></td> <td height="76" colspan="3" valign="middle"> <div align="left"> <p><font size="3" face="Arial, Helvetica, sans-serif"><b> </b></font><font size="1" face="Arial, Helvetica, sans-serif">Diversas prisiones espa&ntilde;olas dan luz a su lado oscuro con el fomento de la expresi&oacute;n art&iacute;stica: flamenco, cartelismo, artes pl&aacute;sticas, teatro.</font></p> <p><font size="1" face="Arial, Helvetica, sans-serif"> <a href="../contenidos/reportaje/070800/1.asp">M&aacute;s Informaci&oacute;n</a></font></p> </div> </td> <td width="9" height="76" valign="top"></td> <td width="6" height="76" valign="top"></td> <td width="9" height="76" valign="top"></td> <td width="9" height="76" valign="top"></td> </tr> <tr> <td width="10" height="27" valign="top"></td> <td width="4" height="27" valign="top"></td> <td height="27" colspan="7" valign="top"> <hr WIDTH="350"> </td> <td width="9" height="27" valign="top"></td> </tr> <tr> <td width="10" height="163" valign="top"></td> <td height="163" colspan="8" valign="top"><font size="3" face="Arial, Helvetica, sans-serif"><b>Danza contempor&aacute;nea: la hermana pobre de las artes esc&eacute;nicas andaluzas.</b></font><font size="1" face="Arial, Helvetica, sans-serif"><br> <a href="http://www.elcultural.com/contenidos/reportaje/230700/1.asp"><img src="http://www.elcultural.com/correo/img/20000727_danza3.jpg" width="148" height="105" border="0" align="left"></a><br> Hasta 1986 Andalucía vivía ajena a la danza contemporánea. Quince años después aún queda mucho por hacer, pero al menos se ha creado una pequeña infraestructura que permite la existencia de varias compañías independientes y se consolida la actividad formativa de instuciones públicas o iniciativas privadas como Endanza (Sevilla) o La Nave (Málaga) <a href="../contenidos/tema/270700/1.asp">M&aacute;s Informaci&oacute;n</a></font> </td> <td width="9" height="163" valign="top"></td> </tr> <tr> <td width="10" height="25" valign="top"></td> <td height="25" colspan="8" valign="top"> <hr WIDTH="100%"> </td> <td width="9" height="25" valign="top"></td> </tr> <tr> <td width="10" height="5" valign="top"></td> <td height="35" colspan="3" rowspan="2" valign="top"><font face="Arial,Helvetica"><font size=-1>Mirada atr&aacute;s<br> </font></font><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/contenidos/matras/040800/1.asp">Jos&eacute; Guerrero, pintor</a></font></td> <td width="5" height="5" valign="top"></td> <td width="9" height="5" valign="top"></td> <td width="6" height="5" valign="top"></td> <td width="150" height="5" valign="top"></td> <td width="9" height="5" valign="top"></td> <td width="9" height="5" valign="top"></td> </tr> <tr> <td width="10" height="30" valign="top"></td> <td width="5" height="30" valign="top"></td> <td width="9" height="30" valign="top"></td> <td height="197" colspan="3" rowspan="4" valign="middle"> <center> <p><font size="2" face="Arial, Helvetica, sans-serif"> La <b>XI Bienal de Flamenco</b> <br> en <i>elcultural.com</i></font><font size="2" face="Arial, Helvetica, sans-serif"><br> <a href="http://www.elcultural.com/bflamenco"><img src="http://www.elcultural.com/correo/img/banner90.gif" width="90" height="90" vspace="2" border="0"></a> </font> </p> </center> </td> <td width="9" height="30" valign="top"></td> </tr> <tr> <td width="10" height="42" valign="top"></td> <td height="42" colspan="3" valign="top"><font face="Arial,Helvetica"><font size=-1>Mirada adelante<br> </font></font><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/contenidos/madelante/210700/1.asp">Rafael García Forcada, pintor</a></font></td> <td width="5" height="42" valign="top"></td> <td width="9" height="42" valign="top"></td> <td width="9" height="42" valign="top"></td> </tr> <tr> <td width="10" height="53" valign="top"></td> <td height="53" colspan="3" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Evento <br> <a href="http://www.elcultural.com/contenidos/evento/020800/1.asp">Alamar 2000, las culturas del mediterráneo en Almería. </a></font></td> <td width="5" height="53" valign="top"></td> <td width="9" height="53" valign="top"></td> <td width="9" height="53" valign="top"></td> </tr> <tr> <td width="10" height="60" valign="top"></td> <td height="60" colspan="4" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Entrevista</font><br> <a href="http://www.elcultural.com/contenidos/entrevista/250700/1.asp"><font face="Arial, Helvetica, sans-serif" size="2">Eduardo Haro Tecglen, "Asisto con horror a la lucha de los poderes por Internet"</font></a><br> </td> <td width="9" height="60" valign="top"></td> <td width="9" height="60" valign="top"></td> </tr> <tr> <td width="10" height="73" valign="top"></td> <td height="73" colspan="8" valign="top"> <center> <p><font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/">portada </a>/ <a href="http://www.elcultural.com/dinamica/index.html">contenidos multimedias de la semana</a> / <a href="mailto:redaccion@elcultural.com">sugerencias</a> / <a href="http://www.elcultural.com/quienes/default.asp"><br> sobre elcultural.com</a>/ <a href="http://www.elcultural.com/prensa/default.asp">dossier de prensa</a></font></font> <br> &nbsp;<br> <font face="Arial,Helvetica"><font size=-2>Si no quieres volver a recibir mensajes de elcultural.com pincha <a href="http://www.elcultural.com/suscripciones/baja.asp">aqu&iacute;</a> y b&oacute;rrate de la Secci&oacute;n Contenidos de Actualidad</font></font> </center> </td> <td width="9" height="73" valign="top"></td> </tr> <tr> <td width="10" height="1" valign="top"><img width="10" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="4" height="1" valign="top"><img width="4" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="121" height="1" valign="top"><img width="121" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="78" height="1" valign="top"><img width="78" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="5" height="1" valign="top"><img width="5" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="9" height="1" valign="top"><img width="9" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="6" height="1" valign="top"><img width="6" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="150" height="1" valign="top"><img width="123" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="9" height="1" valign="top"><img width="9" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="9" height="1" valign="top"><img width="9" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> <td width="173" height="1" valign="top"><img width="173" height="1" src="http://www.elcultural.com/correo/img/transparent.gif"></td> </tr> </table> </body> From noreply@sourceforge.net Wed Aug 9 15:32:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 07:32:55 -0700 Subject: [Python-bugs-list] [Bug #111486] sys.argv in 1.6b1 Message-ID: <200008091432.HAA11671@bush.i.sourceforge.net> Bug #111486, was updated on 2000-Aug-09 07:32 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: sys.argv in 1.6b1 Details: version: 1.6b1 os: Win2k script > import sys > > for a in sys.argv: > print a called with > C:\Temp\site\bin>test 1 2 3 gives following result > C:\Temp\site\bin\test.py the parameters "1 2 3" are lost. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111486&group_id=5470 From noreply@sourceforge.net Wed Aug 9 16:07:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 08:07:37 -0700 Subject: [Python-bugs-list] [Bug #110858] libreadline problems (PR#272) Message-ID: <200008091507.IAA13272@bush.i.sourceforge.net> Bug #110858, was updated on 2000-Aug-01 14:38 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: None Bug Group: Not a Bug Priority: 5 Summary: libreadline problems (PR#272) Details: Jitterbug-Id: 272 Submitted-By: les@infolabs.com Date: Tue, 4 Apr 2000 13:59:28 -0400 (EDT) Version: 1.6a1 OS: Linux Linux 2.2.14, GCC 2.95.2, glibc-2.0.112 Python-1.6a1 immediately dumps core when I start it with the readline module enabled. I'm using libreadline-4.1, and gdb tells me it's segfaulting in libc when it tries to flush stdout. I 'downgraded' to readline-2.2.1 and got it to work by forcing the readline module to link with the static libreadline.a but it won't link to the dynamic libreadline.so. Same thing with today's CVS source (April 4). I strongly suspect the libreadline-4.1 problems are related to threads, but I can't figure out the 2.2.1 linking problem: gcc -shared readline.o -lreadline -ltermcap -o readline.so /usr/local/lib/libreadline.so: In function `tilde_expand_word': /home/les/readline-2.2.1/tilde.c:386: multiple definition of `_DYNAMIC' /usr/lib/crti.o(.dynamic+0x0): first defined here /usr/local/lib/libreadline.so: In function `tilde_expand_word': /home/les/readline-2.2.1/tilde.c:386: multiple definition of `_GLOBAL_OFFSET_TAB LE_' /usr/lib/crti.o(.got.plt+0x0): first defined here /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: bfd assertion fail elflink.h:1498 /usr/bin/ld: readline.so: undefined versioned symbol name __ctype_tolower@@GLIBC _2.0 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status ==================================================================== Audit trail: Mon May 22 17:46:57 2000 guido changed notes Mon May 22 17:46:57 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:38 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] libreadline problems (PR#272) Date: Tue, 04 Apr 2000 16:12:48 -0400 > Full_Name: Les Johnson > Version: 1.6a1 > OS: Linux > Submission from: morr0639.gti.net (208.216.122.39) > > > Linux 2.2.14, GCC 2.95.2, glibc-2.0.112 > > Python-1.6a1 immediately dumps core when I start it with the readline module > enabled. I'm using libreadline-4.1, and gdb tells me it's segfaulting in > libc when it tries to flush stdout. I 'downgraded' to readline-2.2.1 and got > it to work by forcing the readline module to link with the static libreadline.a > but it won't link to the dynamic libreadline.so. Same thing with today's CVS > source (April 4). > > I strongly suspect the libreadline-4.1 problems are related to threads, but I > can't figure out the 2.2.1 linking problem: > > gcc -shared readline.o -lreadline -ltermcap -o readline.so > /usr/local/lib/libreadline.so: In function `tilde_expand_word': > /home/les/readline-2.2.1/tilde.c:386: multiple definition of `_DYNAMIC' > /usr/lib/crti.o(.dynamic+0x0): first defined here > /usr/local/lib/libreadline.so: In function `tilde_expand_word': > /home/les/readline-2.2.1/tilde.c:386: multiple definition of > `_GLOBAL_OFFSET_TAB > LE_' > /usr/lib/crti.o(.got.plt+0x0): first defined here > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: bfd assertion fail elflink.h:1498 > /usr/bin/ld: readline.so: undefined versioned symbol name > __ctype_tolower@@GLIBC > _2.0 > /usr/bin/ld: failed to set dynamic section sizes: Bad value > collect2: ld returned 1 exit status Seems like a bug in /usr/bin/ld to me... Not much else I can do about this here. Try bouncing this off the binutils support list? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:38 By: none Comment: From: Les Johnson Subject: Re: [Python-bugs-list] libreadline problems (PR#272) Date: Thu, 6 Apr 2000 11:01:17 -0400 I originally wrote: >> Linux 2.2.14, GCC 2.95.2, glibc-2.0.112 >> >> Python-1.6a1 immediately dumps core when I start it with the readline module >> enabled. I'm using libreadline-4.1, and gdb tells me it's segfaulting in >> libc when it tries to flush stdout. ...and Guido replied: > Seems like a bug in /usr/bin/ld to me... Not much else I can do about > this here. Try bouncing this off the binutils support list? Not a bug in /usr/bin/ld, but I resolved this one by upgrading from glibc2.0.112 to glibc2.1.3. No more core dumps, and readline works fine. Thanks! - Les Johnson ------------------------------------------------------- Date: 2000-Aug-01 14:38 By: none Comment: What to do? ------------------------------------------------------- Date: 2000-Aug-09 08:07 By: twouters Comment: This wasn't a bug in Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110858&group_id=5470 From noreply@sourceforge.net Wed Aug 9 16:59:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 08:59:25 -0700 Subject: [Python-bugs-list] [Bug #110641] KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Message-ID: <200008091559.IAA15622@bush.i.sourceforge.net> Bug #110641, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Details: Jitterbug-Id: 309 Submitted-By: skip@mojam.com Date: Fri, 28 Apr 2000 17:00:40 -0400 (EDT) Version: 1.5.2, 1.6a2 OS: Linux If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the interpreter exits instead of returning you to the top-level prompt. % python Python 1.5.2+ (#12, Feb 17 2000, 14:52:05) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... % PYTHONSTARTUP= ./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... When run under gdb's control, you can see what's happening: % gdb ./python GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... (gdb) set env PYTHONSTARTUP "" (gdb) run Starting program: /home/beluga/skip/src/python/dist/src/./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... Program received signal SIGINT, Interrupt. 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) bt #0 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) c Continuing. File "", line 2 ^ SyntaxError: invalid syntax >>> It appears that SIGINT isn't handled properly when awaiting console input in certain circumstances. If you can entice the program to continue, things work okay. I don't know interrupt handling from a hole in the ground or I'd investigate further. It is quite annoying, especially considering that Python's input history isn't continuous across sessions... Skip ==================================================================== Audit trail: Mon May 22 17:23:42 2000 guido changed notes Mon May 22 17:23:42 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:40 By: twouters Comment: This seems to be platform specific: On Linux, up-to-date CVS compile, this is reproducible. On BSDI 4.1, however, with an almost-up-to-date CVS compile, ^C doesn't exit the interpreter. ------------------------------------------------------- Date: 2000-Aug-06 04:57 By: twouters Comment: Oh, and it's also definately readline-related. (without readline compiled in, the bug doesn't get triggered, in any case.) ------------------------------------------------------- Date: 2000-Aug-09 08:59 By: twouters Comment: I've been toying with this, and the problem *is* readline. Readline overrides a number of signal handlers, in order to do cleanup when exiting, and apparently does not restore them on exit :-S The signals readline 'overrides' the handlers of are: SIGINT SIGALRM SIGTSTP SIGTTOU SIGTTIN SIGTERM SIGWINCH Which means that the signal handlers for these signals *vanish* when using readline. Interactive mode uses readline, but scripts can themselves, too. I'm not sure why this isn't showing on BSDI, but it might have something to do with the BSD vs the SysV signal handling routines. I'm also not sure if it's possible to fix this problem; it might be a bug in readline, or it might be documented behaviour. But I wasn't able to find a reference to signal handling in the 2.2.1 readline info files. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110641&group_id=5470 From noreply@sourceforge.net Wed Aug 9 17:05:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 09:05:43 -0700 Subject: [Python-bugs-list] [Bug #110641] KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Message-ID: <200008091605.JAA15906@bush.i.sourceforge.net> Bug #110641, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Details: Jitterbug-Id: 309 Submitted-By: skip@mojam.com Date: Fri, 28 Apr 2000 17:00:40 -0400 (EDT) Version: 1.5.2, 1.6a2 OS: Linux If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the interpreter exits instead of returning you to the top-level prompt. % python Python 1.5.2+ (#12, Feb 17 2000, 14:52:05) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... % PYTHONSTARTUP= ./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... When run under gdb's control, you can see what's happening: % gdb ./python GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... (gdb) set env PYTHONSTARTUP "" (gdb) run Starting program: /home/beluga/skip/src/python/dist/src/./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... Program received signal SIGINT, Interrupt. 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) bt #0 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) c Continuing. File "", line 2 ^ SyntaxError: invalid syntax >>> It appears that SIGINT isn't handled properly when awaiting console input in certain circumstances. If you can entice the program to continue, things work okay. I don't know interrupt handling from a hole in the ground or I'd investigate further. It is quite annoying, especially considering that Python's input history isn't continuous across sessions... Skip ==================================================================== Audit trail: Mon May 22 17:23:42 2000 guido changed notes Mon May 22 17:23:42 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:40 By: twouters Comment: This seems to be platform specific: On Linux, up-to-date CVS compile, this is reproducible. On BSDI 4.1, however, with an almost-up-to-date CVS compile, ^C doesn't exit the interpreter. ------------------------------------------------------- Date: 2000-Aug-06 04:57 By: twouters Comment: Oh, and it's also definately readline-related. (without readline compiled in, the bug doesn't get triggered, in any case.) ------------------------------------------------------- Date: 2000-Aug-09 08:59 By: twouters Comment: I've been toying with this, and the problem *is* readline. Readline overrides a number of signal handlers, in order to do cleanup when exiting, and apparently does not restore them on exit :-S The signals readline 'overrides' the handlers of are: SIGINT SIGALRM SIGTSTP SIGTTOU SIGTTIN SIGTERM SIGWINCH Which means that the signal handlers for these signals *vanish* when using readline. Interactive mode uses readline, but scripts can themselves, too. I'm not sure why this isn't showing on BSDI, but it might have something to do with the BSD vs the SysV signal handling routines. I'm also not sure if it's possible to fix this problem; it might be a bug in readline, or it might be documented behaviour. But I wasn't able to find a reference to signal handling in the 2.2.1 readline info files. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110641&group_id=5470 From noreply@sourceforge.net Wed Aug 9 17:04:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 09:04:03 -0700 Subject: [Python-bugs-list] [Bug #110611] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <200008091604.JAA15835@bush.i.sourceforge.net> Bug #110611, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Signal processing bug (Linux threads, readline, whatever else) (PR#196) Details: Jitterbug-Id: 196 Submitted-By: Gregor Hoffleit Date: Tue, 1 Feb 2000 14:43:09 +0100 Version: None OS: None --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-- ==================================================================== Audit trail: Mon Feb 07 12:38:12 2000 guido changed notes Mon Feb 07 12:38:12 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:05 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Wed, 2 Feb 2000 03:04:04 -0500 [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. ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: Gregor Hoffleit Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Wed, 2 Feb 2000 14:25:07 +0100 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 ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: Gregor Hoffleit Subject: Returned mail: User unknown Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET) 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-- ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: Gregor Hoffleit Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Fri, 11 Feb 2000 14:52:42 +0100 --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-- ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110611&group_id=5470 From noreply@sourceforge.net Wed Aug 9 19:10:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 11:10:30 -0700 Subject: [Python-bugs-list] [Bug #110824] Tkinter canvas blow-up: bbox(ALL) == None (PR#133) Message-ID: <200008091810.LAA03606@delerium.i.sourceforge.net> Bug #110824, was updated on 2000-Aug-01 14:10 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Wont Fix Bug Group: 3rd Party Priority: 5 Summary: Tkinter canvas blow-up: bbox(ALL) == None (PR#133) Details: Jitterbug-Id: 133 Submitted-By: aa8vb@yahoo.com Date: Thu, 18 Nov 1999 13:34:44 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 From: "Fredrik Lundh" Date: Tue, 2 Nov 1999 09:53:17 +0100 Subject: Re: Tkinter canvas blow-up: bbox(ALL) == None Randall Hopper wrote: > Apparently if the bounds of the items in a Tk canvas widget exceed > MAXINT, bbox(ALL) returns None. The attached Python script demonstrates > this. > > Intuitively it seems like this is a bug since the contents of the > canvas are maintained in floating point; integer bounds shouldn't be > involved, should they? > > Is this a Tk bug or a Tkinter bug? both. Tkinter uses _getints instead of _getdoubles to convert the bounding box to a tuple... ...but the reason you get None instead of an over- flow error is that Tk returns an empty string in this case (at least in 8.0.5). ------------------------------------------------------------------------------- #!/usr/bin/env python # # canvas_test.py - Demonstrates a bug in Tkinter's Canvas widget # where bbox = None when the bbox exceeds signed MAXINT # (2^31 on most machines). from Tkinter import * # # Create widgets # root = Tk() canvas = Canvas( root, width = 300, height = 300 ) canvas.pack() canvas.create_rectangle( (-100,-100,100,100), outline = "#008000", fill="#800000", width = 3 ) canvas.create_line( (-100,-100,100,100), fill="blue", width=3 ) canvas.create_line( (-100,100,100,-100), fill="blue", width=3 ) canvas.config( scrollregion = canvas.bbox( ALL ) ) # # Zoom the canvas until it's bounds get toasted because they exceed MAXINT # def TimerCB( canvas=canvas ): old = canvas.bbox( ALL ) canvas.scale( ALL, 0.0, 0.0, 2.0, 2.0 ) new = canvas.bbox( ALL ) print "Old = %s, New = %s" % ( old, new ) if new == None: raise SystemError, "canvas's bbox is toast (exceeds signed MAXINT)" canvas.after( 300, TimerCB ) print "CANVAS ZOOM BLOW-UP TEST:\n" canvas.after( 1500, TimerCB ) root.mainloop() ==================================================================== Audit trail: Thu Nov 18 14:06:40 1999 guido changed notes Thu Nov 18 14:06:41 1999 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:11 By: none Comment: bbox should use floats instead of ints, since Tcl/Tk can return them. ------------------------------------------------------- Date: 2000-Aug-09 11:10 By: effbot Comment: this is a Tk feature. the "canvas bbox" command uses integers internally, so there's not much we can do about it :-( ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110824&group_id=5470 From noreply@sourceforge.net Wed Aug 9 19:24:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 11:24:23 -0700 Subject: [Python-bugs-list] [Bug #110605] Tkinter inconsistency (missing methods) (PR#161) Message-ID: <200008091824.LAA04086@delerium.i.sourceforge.net> Bug #110605, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Invalid Bug Group: Feature Request Priority: 5 Summary: Tkinter inconsistency (missing methods) (PR#161) Details: Jitterbug-Id: 161 Submitted-By: Guido van Rossum Date: Thu, 16 Dec 1999 15:49:26 -0500 Version: None OS: None ------- Forwarded Message Date: Thu, 16 Dec 1999 13:48:20 +1100 From: Jonathan Giddy To: guido@python.org Subject: Tkinter inconsistency (missing methods) In Tkinter.py, most scrollable widgets support [xy]view_moveto and [xy]view_scroll, in addition to a basic [xy]view method. However, the Text widget is missing these additional methods. Thanks, Jon. ------- End of Forwarded Message ==================================================================== Audit trail: Wed Jan 12 18:30:41 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110605&group_id=5470 From noreply@sourceforge.net Wed Aug 9 19:27:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 11:27:57 -0700 Subject: [Python-bugs-list] [Bug #111499] PyImport_AppendInittab undocument Message-ID: <200008091827.LAA04228@delerium.i.sourceforge.net> Bug #111499, was updated on 2000-Aug-09 11:27 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PyImport_AppendInittab undocument Details: Both PyImport_AppendInittab and PyImport_ExtendInittab should be documented, but aren't. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111499&group_id=5470 From noreply@sourceforge.net Wed Aug 9 19:28:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 11:28:20 -0700 Subject: [Python-bugs-list] [Bug #110605] Tkinter inconsistency (missing methods) (PR#161) Message-ID: <200008091828.LAA04247@delerium.i.sourceforge.net> Bug #110605, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Fixed Bug Group: Feature Request Priority: 5 Summary: Tkinter inconsistency (missing methods) (PR#161) Details: Jitterbug-Id: 161 Submitted-By: Guido van Rossum Date: Thu, 16 Dec 1999 15:49:26 -0500 Version: None OS: None ------- Forwarded Message Date: Thu, 16 Dec 1999 13:48:20 +1100 From: Jonathan Giddy To: guido@python.org Subject: Tkinter inconsistency (missing methods) In Tkinter.py, most scrollable widgets support [xy]view_moveto and [xy]view_scroll, in addition to a basic [xy]view method. However, the Text widget is missing these additional methods. Thanks, Jon. ------- End of Forwarded Message ==================================================================== Audit trail: Wed Jan 12 18:30:41 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110605&group_id=5470 From noreply@sourceforge.net Wed Aug 9 20:17:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 12:17:16 -0700 Subject: [Python-bugs-list] [Bug #110677] PRIVATE: various minor Tkinter things (PR#388) Message-ID: <200008091917.MAA23517@bush.i.sourceforge.net> Bug #110677, was updated on 2000-Jul-31 14:13 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PRIVATE: various minor Tkinter things (PR#388) Details: Jitterbug-Id: 388 Submitted-By: markus.oberhumer@jk.uni-linz.ac.at Date: Wed, 5 Jul 2000 09:38:11 -0400 (EDT) Version: python CVS OS: all Tkinter.Wm.wm_state() lacks a missing "newstate=None" optional parameter. Tkinter.Text lacks some important methods: [xy]view_moveto, [xy]view_scroll Canvas.CanvasItem & Canvas.Group: - bind lacks an optional "add" param - unbind lacks an optional "funcid" param - tkraise/lower should call self.canvas.tag_XXXX - bbox() return value is inconsistent with Canvas.bbox() ==================================================================== Audit trail: Tue Jul 11 08:24:23 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-09 12:17 By: effbot Comment: the first two items are fixed. I'll look at the Canvas.py stuff later. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110677&group_id=5470 From noreply@sourceforge.net Wed Aug 9 20:25:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 12:25:34 -0700 Subject: [Python-bugs-list] [Bug #110603] Tkinter winfo_visualsavailable method (PR#156) Message-ID: <200008091925.MAA23812@bush.i.sourceforge.net> Bug #110603, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: Tkinter winfo_visualsavailable method (PR#156) Details: Jitterbug-Id: 156 Submitted-By: piers@cs.su.oz.au Date: Thu, 9 Dec 1999 17:09:50 -0500 (EST) Version: 1.5.2 OS: Solaris/Linux/win95 The Tkinter winfo_visualsavailable method fails if there is only one visual available, as the code assumes a list is returned, when in fact Tcl/Tk returns a string in the form '{truecolor 24}' ==================================================================== Audit trail: Tue Dec 14 17:15:16 1999 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110603&group_id=5470 From noreply@sourceforge.net Wed Aug 9 22:22:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 9 Aug 2000 14:22:11 -0700 Subject: [Python-bugs-list] [Bug #111520] Some "Very High Level" functions aren't Message-ID: <200008092122.OAA27985@bush.i.sourceforge.net> Bug #111520, was updated on 2000-Aug-09 14:22 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Some "Very High Level" functions aren't Details: The so-called "Very High Level" functions in the Python C API that take FILE * arguments will not work in a multi-compiler environment; each compiler's notion of a struct FILE will be different. From an implementation standpoint these are very _low_ level functions. The Python documentation for these functions, and the "Extending and embedding" documentation, should make note of this potential problem. BTW, there are situations in which a compiler other than the compiler used to compile Python will be used. Please don't try to make this bug go away by requiring the same compiler be used as was used to compile Python. Edward For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111520&group_id=5470 From noreply@sourceforge.net Thu Aug 10 15:10:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 07:10:57 -0700 Subject: [Python-bugs-list] [Bug #110944] smtplib doesn't use FQDN Message-ID: <200008101410.HAA27417@bush.i.sourceforge.net> Bug #110944, was updated on 2000-Aug-02 11:43 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: None Bug Group: None Priority: 5 Summary: smtplib doesn't use FQDN Details: When talking to an SMTP server smtplib says HELO "name" where name is the result of: name = socket.gethostbyaddr(name)[0] Unfortunately that line isn't guarenteed to return the FQDN of the machine and so some MTAs with certain configurations (in my case postfix) reject the mail as they insist on a FQDN. Those MTAs that don't insist on a FQDN arent going to complain if they get one either so changing this behaviour seems desirable. This code appears twice...once around line 295 and again around line 312. The fix would seem to be listed at http://www.python.org/doc/current/lib/module-socket.html. "To find the fully qualified domain name, check hostname and the items of aliaslist for an entry containing at least one period." I don't know enough python to provide a patch...sorry. Thanks, Andrew BTW I have submitted this bug against the version in mailman as well For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110944&group_id=5470 From noreply@sourceforge.net Thu Aug 10 15:12:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 07:12:06 -0700 Subject: [Python-bugs-list] [Bug #110944] smtplib doesn't use FQDN Message-ID: <200008101412.HAA27434@bush.i.sourceforge.net> Bug #110944, was updated on 2000-Aug-02 11:43 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: None Bug Group: None Priority: 5 Summary: smtplib doesn't use FQDN Details: When talking to an SMTP server smtplib says HELO "name" where name is the result of: name = socket.gethostbyaddr(name)[0] Unfortunately that line isn't guarenteed to return the FQDN of the machine and so some MTAs with certain configurations (in my case postfix) reject the mail as they insist on a FQDN. Those MTAs that don't insist on a FQDN arent going to complain if they get one either so changing this behaviour seems desirable. This code appears twice...once around line 295 and again around line 312. The fix would seem to be listed at http://www.python.org/doc/current/lib/module-socket.html. "To find the fully qualified domain name, check hostname and the items of aliaslist for an entry containing at least one period." I don't know enough python to provide a patch...sorry. Thanks, Andrew BTW I have submitted this bug against the version in mailman as well Follow-Ups: Date: 2000-Aug-10 07:12 By: nowonder Comment: closed by patch #101103 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110944&group_id=5470 From noreply@sourceforge.net Thu Aug 10 15:13:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 07:13:23 -0700 Subject: [Python-bugs-list] [Bug #111499] PyImport_AppendInittab undocument Message-ID: <200008101413.HAA09255@delerium.i.sourceforge.net> Bug #111499, was updated on 2000-Aug-09 11:27 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PyImport_AppendInittab undocument Details: Both PyImport_AppendInittab and PyImport_ExtendInittab should be documented, but aren't. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111499&group_id=5470 From noreply@sourceforge.net Thu Aug 10 15:14:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 07:14:37 -0700 Subject: [Python-bugs-list] [Bug #111520] Some "Very High Level" functions aren't Message-ID: <200008101414.HAA09369@delerium.i.sourceforge.net> Bug #111520, was updated on 2000-Aug-09 14:22 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Some "Very High Level" functions aren't Details: The so-called "Very High Level" functions in the Python C API that take FILE * arguments will not work in a multi-compiler environment; each compiler's notion of a struct FILE will be different. From an implementation standpoint these are very _low_ level functions. The Python documentation for these functions, and the "Extending and embedding" documentation, should make note of this potential problem. BTW, there are situations in which a compiler other than the compiler used to compile Python will be used. Please don't try to make this bug go away by requiring the same compiler be used as was used to compile Python. Edward For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111520&group_id=5470 From noreply@sourceforge.net Thu Aug 10 17:41:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 09:41:06 -0700 Subject: [Python-bugs-list] [Bug #111582] Missing "sysconf" in the POSIX module Message-ID: <200008101641.JAA14412@delerium.i.sourceforge.net> Bug #111582, was updated on 2000-Aug-10 09:41 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Missing "sysconf" in the POSIX module Details: I had the problem to determine the page size of an sparc computer. Looking at man page shows sysconf are the way to do an are part of POSIX.2. But the POSIX module dosen't contains sysconf(). For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111582&group_id=5470 From noreply@sourceforge.net Thu Aug 10 17:52:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 09:52:24 -0700 Subject: [Python-bugs-list] [Bug #111586] 1.6b1: PythonPath Message-ID: <200008101652.JAA14778@delerium.i.sourceforge.net> Bug #111586, was updated on 2000-Aug-10 09:52 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: 1.6b1: PythonPath Details: version: Python 1.6b1 os: Win2k i added an additional path to the PythonPath registry entry, but python ignores the additional path. (i used the windows installer, after deinstalling 1.5.2) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111586&group_id=5470 From noreply@sourceforge.net Thu Aug 10 17:56:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 09:56:34 -0700 Subject: [Python-bugs-list] [Bug #111582] Missing "sysconf" in the POSIX module Message-ID: <200008101656.JAA14971@delerium.i.sourceforge.net> Bug #111582, was updated on 2000-Aug-10 09:41 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: Feature Request Priority: 5 Summary: Missing "sysconf" in the POSIX module Details: I had the problem to determine the page size of an sparc computer. Looking at man page shows sysconf are the way to do an are part of POSIX.2. But the POSIX module dosen't contains sysconf(). Follow-Ups: Date: 2000-Aug-10 09:56 By: fdrake Comment: sysconf() has been added since 1.5.2; it will be present in 1.6 and 2.0. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111582&group_id=5470 From noreply@sourceforge.net Thu Aug 10 18:01:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 10:01:45 -0700 Subject: [Python-bugs-list] [Bug #110868] PythonWin crash on dead keys (PR#372) Message-ID: <200008101701.KAA15132@delerium.i.sourceforge.net> Bug #110868, was updated on 2000-Aug-01 14:42 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: PythonWin crash on dead keys (PR#372) Details: Jitterbug-Id: 372 Submitted-By: gottfried.ganssauge@dynix.de Date: Tue, 27 Jun 2000 05:23:09 -0400 (EDT) Version: 1.5.2 OS: Windows 2000 I'm using PyWin32 build 132, but the problem occurs with build 129 as well. Every time I hit one of the dead keys on my keyboard (`, ^) PythonWin crashes. I traced the error back to the routine ui_translate_vk() in win32uimodule.cpp. The call to ToAsciiEx() with a dead key's scan code returns -1 and in the following call to PyString_FromStringAndSize() this eventually leads to the crash. In my opininion the reason for that lies before the call to this routine. pywin hooks WM_KEYDOWN in several places and doesn't check for dead keys but tries to translate the scan code to an ASCII character. With dead keys this obviously must fail. Windows itself already does the correct translation as described in the Platform SDK article about Dead-Character Messages: Some non-English keyboards contain character keys that are not expected to produce characters by themselves. Instead, they are used to add a diacritic to the character produced by the subsequent keystroke. These keys are called dead keys. The circumflex key on a German keyboard is an example of a dead key. To enter the character consisting of an "o" with a circumflex, a German user would type the circumflex key followed by the "o" key. The window with the keyboard focus would receive the following sequence of messages: WM_KEYDOWN WM_DEADCHAR WM_KEYUP WM_KEYDOWN WM_CHAR WM_KEYUP Consequently pywin should ignore WM_KEYDOWN messages completely if they are produced by a dead key. I tried to implement that using the current win32api implementation, but unfortunately the necessary API-Function to find out if a key is a dead key are not provided in the current implementation; namely the MapVirtualKey(Ex) function. Cheers, and keep up the good work Gottfried ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to 3rdpartybug Follow-Ups: Date: 2000-Aug-01 14:42 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] PythonWin crash on dead keys (PR#372) Date: Wed, 28 Jun 2000 10:33:26 +1000 Thanks for reporting this. Ill look into it. In general, this bug mechanism is for Python itself, and not the Python for Win32 extensions. Its probably best to simply mail future bugs in the Win32 stuff directly to me. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > gottfried.ganssauge@dynix.de > Sent: Tuesday, 27 June 2000 11:08 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PythonWin crash on dead keys (PR#372) > > > Full_Name: Gottfried Ganßauge > Version: 1.5.2 > OS: Windows 2000 > Submission from: joshua2go.dynix.de (195.21.130.43) > > > I'm using PyWin32 build 132, but the problem occurs with build > 129 as well. > > Every time I hit one of the dead keys on my keyboard (`, ^) > PythonWin crashes. > I traced the error back to the routine ui_translate_vk() in > win32uimodule.cpp. > The call to ToAsciiEx() with a dead key's scan code returns -1 and in the > following call to PyString_FromStringAndSize() this eventually > leads to the > crash. > In my opininion the reason for that lies before the call to this routine. > pywin hooks WM_KEYDOWN in several places and doesn't check for > dead keys but > tries to translate the scan code to an ASCII character. > With dead keys this obviously must fail. > Windows itself already does the correct translation as described in the > Platform SDK article about Dead-Character Messages: > > Some non-English keyboards contain character keys that are not > expected to > produce characters by themselves. Instead, they are used to add > a diacritic to > the character produced by the subsequent keystroke. These keys > are called dead > keys. The circumflex key on a German keyboard is an example of a > dead key. To > enter the character consisting of an "o" with a circumflex, a > German user would > type the circumflex key followed by the "o" key. The window with > the keyboard > focus would receive the following sequence of messages: > > WM_KEYDOWN > WM_DEADCHAR > WM_KEYUP > WM_KEYDOWN > WM_CHAR > WM_KEYUP > > > Consequently pywin should ignore WM_KEYDOWN messages completely > if they are > produced by a dead key. > I tried to implement that using the current win32api implementation, but > unfortunately the necessary API-Function to find out if a key is > a dead key are > not provided in the current implementation; namely the MapVirtualKey(Ex) > function. > > Cheers, and keep up the good work > > Gottfried > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > ------------------------------------------------------- Date: 2000-Aug-10 10:01 By: twouters Comment: Feel free to close this report if you think it shouldn't be here, Mark. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110868&group_id=5470 From noreply@sourceforge.net Thu Aug 10 19:43:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 11:43:50 -0700 Subject: [Python-bugs-list] [Bug #110823] Tkinter missing button state symbols (PR#132) Message-ID: <200008101843.LAA18885@delerium.i.sourceforge.net> Bug #110823, was updated on 2000-Aug-01 14:10 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: Tkinter missing button state symbols (PR#132) Details: Jitterbug-Id: 132 Submitted-By: aa8vb@yahoo.com Date: Thu, 18 Nov 1999 08:16:55 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 I have: picture.bind( "" , click_cb ) picture.bind( "", click_cb ) In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. Where are the Tkinter constants for these? Or how should one distinguish between a press and release in a callback? (I want to avoid having a separate callback for each type of event.) ==================================================================== Audit trail: Thu Nov 18 10:42:46 1999 guido changed notes Thu Nov 18 10:42:46 1999 guido moved from incoming to notabug Thu Nov 18 14:07:59 1999 guido changed notes Thu Nov 18 14:07:59 1999 guido moved from notabug to request Follow-Ups: Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 10:41:31 -0500 > Full_Name: Randall Hopper > Version: 1.5.2 > OS: IRIX 6.5 > Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) > > > I have: > > picture.bind( "" , click_cb ) > picture.bind( "", click_cb ) > > In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. > > Where are the Tkinter constants for these? Or how should one distinguish > between a press and release in a callback? > > (I want to avoid having a separate callback for each type of event.) This is not a question for the bugs list. Write to help@python.org or use the newsgroup for help. I don't know offhand what the answer is to your question; I suspect that the answer is in the Tcl/Tk man page for the bind command though. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: From: Randall Hopper Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 14:04:13 -0500 Guido van Rossum: |> Full_Name: Randall Hopper |> Version: 1.5.2 |> OS: IRIX 6.5 |> Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) |> |> |> I have: |> |> picture.bind( "" , click_cb ) |> picture.bind( "", click_cb ) |> |> In click_cb(), event.state is 0 for ButtonPress and 256 for ButtonRelease. |> |> Where are the Tkinter constants for these? Or how should one distinguish |> between a press and release in a callback? |> |> (I want to avoid having a separate callback for each type of event.) | |This is not a question for the bugs list. | |Write to help@python.org or use the newsgroup for help. I don't know |offhand what the answer is to your question; I suspect that the answer |is in the Tcl/Tk man page for the bind command though. My fault. I should have rephrased the question into a statement. Tkinter does not provide symbol defines for event.state values (%s keyword in Tcl). Tcl doesn't either, but it would be useful if Tkinter did. This is a small enhancement request rather than a hard bug, but I thought the submission form was for probably applicable for both. Thanks, Randall ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Date: Thu, 18 Nov 1999 14:05:57 -0500 Yes, requests are okay. Sorry for the confusion. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: Should add a symbol as he suggests. ------------------------------------------------------- Date: 2000-Aug-09 02:21 By: effbot Comment: IIRC, these constants are platform (X library) dependent (they have to be exported from _tkinter.c, not Tkconstants.py). I'll investigate. Feel free to assign the bug to me if you like. ------------------------------------------------------- Date: 2000-Aug-10 11:43 By: gvanrossum Comment: /F, go for it! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110823&group_id=5470 From noreply@sourceforge.net Thu Aug 10 19:45:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 11:45:14 -0700 Subject: [Python-bugs-list] [Bug #110599] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <200008101845.LAA19000@delerium.i.sourceforge.net> Bug #110599, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Details: Jitterbug-Id: 102 Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Date: Mon, 11 Oct 1999 13:00:07 +0200 Version: None OS: None 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 **************************************************************************** ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:05 By: none Comment: From: Jeremy Hylton Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT) >>>>> "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 ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 09:19:44 +0200 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 ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 08:57:25 -0400 > 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/) ------------------------------------------------------- Date: 2000-Jul-31 14:05 By: none Comment: From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 16:34:39 +0200 >... >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 ------------------------------------------------------- Date: 2000-Aug-10 11:45 By: gvanrossum Comment: Sorry, I can't take this. It's an issue though! There are a bunch of signal related bugs in Linux... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110599&group_id=5470 From noreply@sourceforge.net Thu Aug 10 19:48:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 11:48:49 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008101848.LAA19068@delerium.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 4 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- Date: 2000-Aug-10 11:48 By: gvanrossum Comment: No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Thu Aug 10 19:51:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 11:51:15 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008101851.LAA19217@delerium.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 4 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- Date: 2000-Aug-10 11:48 By: gvanrossum Comment: No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } ------------------------------------------------------- Date: 2000-Aug-10 11:51 By: gvanrossum Comment: Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Thu Aug 10 19:52:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 11:52:01 -0700 Subject: [Python-bugs-list] [Bug #110610] .pyc writing/reading race condition (PR#189) Message-ID: <200008101852.LAA19222@delerium.i.sourceforge.net> Bug #110610, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: Later Bug Group: None Priority: 1 Summary: .pyc writing/reading race condition (PR#189) Details: Jitterbug-Id: 189 Submitted-By: gudo@python.org Date: Mon, 24 Jan 2000 14:27:24 -0500 (EST) Version: 1.5.2 OS: any Patrick Miller reminded me that there's still a race condition in the reading and writing of .pyc files. If two processes decide to write the .pyc, and a third reads the header after the first complete but before the second starts, but reads the rest of the file after the second starts but before it is done, the third can read corrupt data (and won't fall back to reading the .py source). Solution: when writing the .pyc file, (1) unlink the file before writing, (2) use open() with the Unix flags that fail creation if the file exists (and then just treat it like any open failure when writing the .pyc file). ==================================================================== Audit trail: Mon Jan 24 14:28:42 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-10 11:52 By: gvanrossum Comment: No time to fix this now... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110610&group_id=5470 From noreply@sourceforge.net Fri Aug 11 00:04:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 16:04:09 -0700 Subject: [Python-bugs-list] [Bug #110868] PythonWin crash on dead keys (PR#372) Message-ID: <200008102304.QAA13915@bush.i.sourceforge.net> Bug #110868, was updated on 2000-Aug-01 14:42 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Fixed Bug Group: 3rd Party Priority: 5 Summary: PythonWin crash on dead keys (PR#372) Details: Jitterbug-Id: 372 Submitted-By: gottfried.ganssauge@dynix.de Date: Tue, 27 Jun 2000 05:23:09 -0400 (EDT) Version: 1.5.2 OS: Windows 2000 I'm using PyWin32 build 132, but the problem occurs with build 129 as well. Every time I hit one of the dead keys on my keyboard (`, ^) PythonWin crashes. I traced the error back to the routine ui_translate_vk() in win32uimodule.cpp. The call to ToAsciiEx() with a dead key's scan code returns -1 and in the following call to PyString_FromStringAndSize() this eventually leads to the crash. In my opininion the reason for that lies before the call to this routine. pywin hooks WM_KEYDOWN in several places and doesn't check for dead keys but tries to translate the scan code to an ASCII character. With dead keys this obviously must fail. Windows itself already does the correct translation as described in the Platform SDK article about Dead-Character Messages: Some non-English keyboards contain character keys that are not expected to produce characters by themselves. Instead, they are used to add a diacritic to the character produced by the subsequent keystroke. These keys are called dead keys. The circumflex key on a German keyboard is an example of a dead key. To enter the character consisting of an "o" with a circumflex, a German user would type the circumflex key followed by the "o" key. The window with the keyboard focus would receive the following sequence of messages: WM_KEYDOWN WM_DEADCHAR WM_KEYUP WM_KEYDOWN WM_CHAR WM_KEYUP Consequently pywin should ignore WM_KEYDOWN messages completely if they are produced by a dead key. I tried to implement that using the current win32api implementation, but unfortunately the necessary API-Function to find out if a key is a dead key are not provided in the current implementation; namely the MapVirtualKey(Ex) function. Cheers, and keep up the good work Gottfried ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to 3rdpartybug Follow-Ups: Date: 2000-Aug-01 14:42 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] PythonWin crash on dead keys (PR#372) Date: Wed, 28 Jun 2000 10:33:26 +1000 Thanks for reporting this. Ill look into it. In general, this bug mechanism is for Python itself, and not the Python for Win32 extensions. Its probably best to simply mail future bugs in the Win32 stuff directly to me. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > gottfried.ganssauge@dynix.de > Sent: Tuesday, 27 June 2000 11:08 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PythonWin crash on dead keys (PR#372) > > > Full_Name: Gottfried Ganßauge > Version: 1.5.2 > OS: Windows 2000 > Submission from: joshua2go.dynix.de (195.21.130.43) > > > I'm using PyWin32 build 132, but the problem occurs with build > 129 as well. > > Every time I hit one of the dead keys on my keyboard (`, ^) > PythonWin crashes. > I traced the error back to the routine ui_translate_vk() in > win32uimodule.cpp. > The call to ToAsciiEx() with a dead key's scan code returns -1 and in the > following call to PyString_FromStringAndSize() this eventually > leads to the > crash. > In my opininion the reason for that lies before the call to this routine. > pywin hooks WM_KEYDOWN in several places and doesn't check for > dead keys but > tries to translate the scan code to an ASCII character. > With dead keys this obviously must fail. > Windows itself already does the correct translation as described in the > Platform SDK article about Dead-Character Messages: > > Some non-English keyboards contain character keys that are not > expected to > produce characters by themselves. Instead, they are used to add > a diacritic to > the character produced by the subsequent keystroke. These keys > are called dead > keys. The circumflex key on a German keyboard is an example of a > dead key. To > enter the character consisting of an "o" with a circumflex, a > German user would > type the circumflex key followed by the "o" key. The window with > the keyboard > focus would receive the following sequence of messages: > > WM_KEYDOWN > WM_DEADCHAR > WM_KEYUP > WM_KEYDOWN > WM_CHAR > WM_KEYUP > > > Consequently pywin should ignore WM_KEYDOWN messages completely > if they are > produced by a dead key. > I tried to implement that using the current win32api implementation, but > unfortunately the necessary API-Function to find out if a key is > a dead key are > not provided in the current implementation; namely the MapVirtualKey(Ex) > function. > > Cheers, and keep up the good work > > Gottfried > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > ------------------------------------------------------- Date: 2000-Aug-10 10:01 By: twouters Comment: Feel free to close this report if you think it shouldn't be here, Mark. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110868&group_id=5470 From noreply@sourceforge.net Fri Aug 11 00:39:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 16:39:48 -0700 Subject: [Python-bugs-list] [Bug #111620] lots of use of send() without verifying amount of data sent. Message-ID: <200008102339.QAA29157@delerium.i.sourceforge.net> Bug #111620, was updated on 2000-Aug-10 16:39 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: lots of use of send() without verifying amount of data sent. Details: a quick grep of the standard python library (below) shows that there is lots of unchecked use of the send() function. Every unix system I've every used states that send() returns the number of bytes sent, which can be < length(). Using socket.send(s) without verifying that the return value is equal to the length of s is careless and can result in loss of data. I just submitted a patch for smtplib's use of send(), have patched a piece of Zope the same way, and get the feeling that it's becoming standard to call send() without checking that the amount of data sent is the intended amount. While this is OK for a quick script, I don't feel it's OK for library code or anything that might be used in production. scott For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111620&group_id=5470 From noreply@sourceforge.net Fri Aug 11 05:57:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 10 Aug 2000 21:57:52 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008110457.VAA06867@delerium.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 4 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- Date: 2000-Aug-10 11:48 By: gvanrossum Comment: No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } ------------------------------------------------------- Date: 2000-Aug-10 11:51 By: gvanrossum Comment: Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code. ------------------------------------------------------- Date: 2000-Aug-10 21:57 By: tim_one Comment: It's curious that in the change mail SF generated, leading indentation was *not* lost. This must be a browser display thing. Anyway, by eyeball the syntax checker has two bugs: 1. Infinite loop when looking at an exponent. x while (isdigit(*s)) digits++; should be x while (isdigit(*s)) {digits++; s++;) 2. Like atof, stops at an invalid character. Before the x return s; it should have, e.g., x while (ispace(*s)) ++s; x if (*s) return NULL; although I'm not sure what the assumptions are about the input to this function. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Fri Aug 11 12:38:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 04:38:27 -0700 Subject: [Python-bugs-list] [Bug #111667] unicode core dump Message-ID: <200008111138.EAA19691@delerium.i.sourceforge.net> Bug #111667, was updated on 2000-Aug-11 04:38 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: unicode core dump Details: This two-liner faults inside PyUnicode_EncodeRawUnicodeEscape >>> import cPickle >>> cPickle.dumps(u'') For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111667&group_id=5470 From noreply@sourceforge.net Fri Aug 11 13:42:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 05:42:18 -0700 Subject: [Python-bugs-list] [Bug #111667] unicode core dump Message-ID: <200008111242.FAA21852@delerium.i.sourceforge.net> Bug #111667, was updated on 2000-Aug-11 04:38 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: unicode core dump Details: This two-liner faults inside PyUnicode_EncodeRawUnicodeEscape >>> import cPickle >>> cPickle.dumps(u'') Follow-Ups: Date: 2000-Aug-11 05:42 By: lemburg Comment: On which platform do you get this seg fault ? FYI, I can reproduce it on Linux, but the gdb stack trace doesn't really show any hint as to what is failing... could be a compiler optimization bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111667&group_id=5470 From noreply@sourceforge.net Fri Aug 11 14:39:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 06:39:18 -0700 Subject: [Python-bugs-list] [Bug #110833] linker options documentation (PR#195) Message-ID: <200008111339.GAA23706@delerium.i.sourceforge.net> Bug #110833, was updated on 2000-Aug-01 14:13 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: linker options documentation (PR#195) Details: Jitterbug-Id: 195 Submitted-By: John-Mark Gurney Date: Sun, 30 Jan 2000 18:09:56 -0800 Version: None OS: None I have found out that I need to add -Xlinker -export-dynamic to the gcc command to compile a program linked w/ the libpython.a library... if you do not specify this option, all unreferenced symbols will be discarded... please document this requirement in the documentation, and after that has happened, close this bug report... Thanks. -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson ==================================================================== Audit trail: Mon Feb 07 12:37:05 2000 guido changed notes Mon Feb 07 12:37:05 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:13 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 31 Jan 2000 12:25:49 -0500 > I have found out that I need to add -Xlinker -export-dynamic to the gcc > command to compile a program linked w/ the libpython.a library... if you > do not specify this option, all unreferenced symbols will be discarded... > > please document this requirement in the documentation, and after that has > happened, close this bug report... I read your bug report 191 and I think it may be platform specific, or a bug in how you link with Python, since I cannot reproduce this here on Solaris. Until we are clear on this we can't fix the documentation, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: none Comment: From: John-Mark Gurney Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 31 Jan 2000 11:40:12 -0800 Guido van Rossum scribbled this message on Jan 31: > > I have found out that I need to add -Xlinker -export-dynamic to the gcc > > command to compile a program linked w/ the libpython.a library... if you > > do not specify this option, all unreferenced symbols will be discarded... > > > > please document this requirement in the documentation, and after that has > > happened, close this bug report... > > I read your bug report 191 and I think it may be platform specific, or > a bug in how you link with Python, since I cannot reproduce this here > on Solaris. I would try it under Solaris, but I don't have the time right now to compile up the latest GNU ld on solaris, to make sure that it is compiler specific... > Until we are clear on this we can't fix the documentation, sorry. I would think that you would want to document such a behavior considering just how many people happen to use gcc... I am using gcc 2.7.2.3 and GNU ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1, I would assume you'd want to document it so that people like myself, don't run into this problem... 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... -- John-Mark Gurney Voice: +1 408 975 9651 Cu Networking "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 31 Jan 2000 15:35:35 -0500 > Guido van Rossum scribbled this message on Jan 31: > > > I have found out that I need to add -Xlinker -export-dynamic to the gcc > > > command to compile a program linked w/ the libpython.a library... if you > > > do not specify this option, all unreferenced symbols will be discarded... > > > > > > please document this requirement in the documentation, and after that has > > > happened, close this bug report... > > > > I read your bug report 191 and I think it may be platform specific, or > > a bug in how you link with Python, since I cannot reproduce this here > > on Solaris. > > I would try it under Solaris, but I don't have the time right now to > compile up the latest GNU ld on solaris, to make sure that it is compiler > specific... > > > Until we are clear on this we can't fix the documentation, sorry. > > I would think that you would want to document such a behavior considering > just how many people happen to use gcc... I am using gcc 2.7.2.3 and GNU > ld 2.9.1, and considering the number of people that are using GNU ld 2.9.1, > I would assume you'd want to document it so that people like myself, don't > run into this problem... > > 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... This (that it's GNU ld specific) is information that you didn't explain first. I am probably not using GNU ld, which may explain why I couldn't reproduce your problem. If you want to save me the most time, please suggest the exact patch for the documentation, using the latest version of the docs from the CVS tree. (python.org/download/cvs.html) To save me at least some time, write a paragraph of text and give me at least a hint on which section of which document it should be inserted into, and we'll figure it out from there. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] please resolve 191.. (PR#195) Date: Mon, 07 Feb 2000 12:55:20 -0500 > 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/) ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: none Comment: Still waiting for a patch... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110833&group_id=5470 From noreply@sourceforge.net Fri Aug 11 14:49:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 06:49:32 -0700 Subject: [Python-bugs-list] [Bug #110639] test_fork1 hangs with 1.6a2 on Linux (PR#296) Message-ID: <200008111349.GAA24092@delerium.i.sourceforge.net> Bug #110639, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: test_fork1 hangs with 1.6a2 on Linux (PR#296) Details: Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:09 By: none Comment: From: Fred L. Drake, Jr. Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu Apr 13 15:55:33 2000 Oliver, We're aware of it, but haven't figured out the exact problem yet. If you can provide additional information on the observed behavior, that would be good. I get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, and blocks. I'm suspecting a pthread implementation problem, but haven't had enough time to really dig into it sufficiently to be sure. -Fred ------------------------------------------------------- Date: 2000-Jul-31 14:09 By: none Comment: From: Oliver Andrich Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 22:26:08 +0200 Hi, well what I have discovered so far is. - Normal optimizations for Mandrake packages results in a sure segfault. - Normal python optimizations (jst calling make) causes hangs sometimes works. A look at ps ax shows, that there exist 6 active python "processes" (the parent process and 5 threads) and one defunct python process (the child). So thet child terminates correctly as I already mentioned. But the os.waitpid doesn't discover that the child has already exited. Things I will to tonight: - write a complete cversion of the testcode - compile python against another thread library - compile python against the most recent glibc snapshot - compile python on a RedHat 6.1 system Hopefully I get some more insights. Sadly, I am not good at c debugging, as I am a Python code by choice and a C coder who has written his last C code five years ago (a really program not just a Python extension ;-). Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred ------------------------------------------------------- Date: 2000-Jul-31 14:09 By: none Comment: From: Oliver Andrich Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 23:38:08 +0200 Hi, I just checked the following to things. I patched the threading to work with GNU pth and get the same results. When I run the test script with Python 1.5.2 on the same machine, that means same glibc and so on, it works fine. I compared the threading code of Python 1.5.2 and 1.6.a2 and it doesn't seem to differ at all. Same for the posixcode as far it is relevant for the test. I am a little bit irritated by this. Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred ------------------------------------------------------- Date: 2000-Aug-11 06:49 By: fdrake Comment: I do not currently have ready access to an SMP machine, so I can't tell if this is fixed or not. I cannot reproduce this using a uniprocessor running Mandrake 7.1 (kernel 2.2.15-4mdk). This bug may also be related to the use of the GNU Pth pthreads implementation; we should find out which threading library was being used. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110639&group_id=5470 From noreply@sourceforge.net Fri Aug 11 14:59:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 06:59:45 -0700 Subject: [Python-bugs-list] [Bug #110613] makesetup support for RPATH (PR#202) Message-ID: <200008111359.GAA24446@delerium.i.sourceforge.net> Bug #110613, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: makesetup support for RPATH (PR#202) Details: Jitterbug-Id: 202 Submitted-By: aa8vb@yahoo.com Date: Fri, 11 Feb 2000 07:12:28 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 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 ==================================================================== Audit trail: Wed Feb 23 21:30:21 2000 guido changed notes Wed Feb 23 21:30:21 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-02 23:10 By: fdrake Comment: The current CVS version of makesetup appears to handle -rpath and -R, but not --rpath. Is neither of the alternatives sufficient for FreeBSD? ------------------------------------------------------- Date: 2000-Aug-11 06:59 By: fdrake Comment: -R and -rpath are supported; --rpath support is added in Modules/makesetup revision 1.27. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110613&group_id=5470 From noreply@sourceforge.net Fri Aug 11 15:23:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 07:23:36 -0700 Subject: [Python-bugs-list] [Bug #111620] lots of use of send() without verifying amount of data sent. Message-ID: <200008111423.HAA25334@delerium.i.sourceforge.net> Bug #111620, was updated on 2000-Aug-10 16:39 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: lots of use of send() without verifying amount of data sent. Details: a quick grep of the standard python library (below) shows that there is lots of unchecked use of the send() function. Every unix system I've every used states that send() returns the number of bytes sent, which can be < length(). Using socket.send(s) without verifying that the return value is equal to the length of s is careless and can result in loss of data. I just submitted a patch for smtplib's use of send(), have patched a piece of Zope the same way, and get the feeling that it's becoming standard to call send() without checking that the amount of data sent is the intended amount. While this is OK for a quick script, I don't feel it's OK for library code or anything that might be used in production. scott Follow-Ups: Date: 2000-Aug-11 07:23 By: twouters Comment: As Guido and Fred pointed out on python-dev, you are confusing 'send()' with 'write()'. 'send()' either returns an error code (when the message is too large) or succeeds. It doesn't do half-writes. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111620&group_id=5470 From noreply@sourceforge.net Fri Aug 11 15:48:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 07:48:54 -0700 Subject: [Python-bugs-list] [Bug #111620] lots of use of send() without verifying amount of data sent. Message-ID: <200008111448.HAA11029@bush.i.sourceforge.net> Bug #111620, was updated on 2000-Aug-10 16:39 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: Wont Fix Bug Group: None Priority: 5 Summary: lots of use of send() without verifying amount of data sent. Details: a quick grep of the standard python library (below) shows that there is lots of unchecked use of the send() function. Every unix system I've every used states that send() returns the number of bytes sent, which can be < length(). Using socket.send(s) without verifying that the return value is equal to the length of s is careless and can result in loss of data. I just submitted a patch for smtplib's use of send(), have patched a piece of Zope the same way, and get the feeling that it's becoming standard to call send() without checking that the amount of data sent is the intended amount. While this is OK for a quick script, I don't feel it's OK for library code or anything that might be used in production. scott Follow-Ups: Date: 2000-Aug-11 07:23 By: twouters Comment: As Guido and Fred pointed out on python-dev, you are confusing 'send()' with 'write()'. 'send()' either returns an error code (when the message is too large) or succeeds. It doesn't do half-writes. ------------------------------------------------------- Date: 2000-Aug-11 07:48 By: gvanrossum Comment: (And I'm not so sure that write() can do partial writes either!) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111620&group_id=5470 From noreply@sourceforge.net Fri Aug 11 17:37:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 09:37:29 -0700 Subject: [Python-bugs-list] [Bug #111690] Bug: dictionary with >= 8192 keys not initialized correctly Message-ID: <200008111637.JAA14728@bush.i.sourceforge.net> Bug #111690, was updated on 2000-Aug-11 09:37 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Bug: dictionary with >= 8192 keys not initialized correctly Details: Original posting to comp.lang.python: Save this to a file dictbug.py: print 'd1 = {' for i in xrange(8191): print str(i) + ': None,' print '}' print 'd2 = {' for i in xrange(8192): print str(i) + ': None,' print '}' print 'print len(d1)' print 'print len(d2)' Then run: python dictbug.py > tmp.py python tmp.py The output is: 8191 0 I tested this with: Python 1.5.2 (#1, Apr 28 2000, 11:50:55) [C] on osf1V5 Python 1.6b1 (#1, Aug 4 2000, 22:34:57) [C] on osf1V5 Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 If a dictionary is generated dynamically, e.g. by adding keys in a loop, there is no problem if there are >= 8192 keys. If there is an inherent problem with large dictionaries, it would be good if Python could at least raise an exception, e.g. SystemError. Ralf A reply to that posting: That's strange. I get a SyntaxError because the limit of subnodes for an expression was set to 8192: Python 2.0b1 (#2, Aug 7 2000, 10:06:00) [GCC 2.95.2 19991024 (release)] on linux2 File "dumm3.py", line 16386 8191: None, ^ SyntaxError: expression too long But then this probably was fixed after the 1.6b1 fork ... You should submit this to the bug tracker at sourceforge: http://sourceforge.net/bugs/?group_id=5470 Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111690&group_id=5470 From special@buoinet.net Fri Aug 11 17:39:48 2000 From: special@buoinet.net (special@buoinet.net) Date: Fri, 11 Aug 2000 12:39:48 -0400 (EDT) Subject: [Python-bugs-list] $9.95/ mo web hosting (PR#428) Message-ID: <20000811163948.A71601D213@dinsdale.python.org> Sir: I noticed your website and am simply offering you what could be a much better deal on your web hosting... If you think you might be interested, go to our site: http://www.buoinet.net see what we have to offer... Our hosting plans start at $9.95... Thanks again for your time - you wont be getting any more email from us unless you email us requesting more information. If you represent a web design firm, we offer bulk discounting as well. Very Truly Yours -Mike Carlson www.buoinet.net This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line. From noreply@sourceforge.net Fri Aug 11 20:19:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 12:19:02 -0700 Subject: [Python-bugs-list] [Bug #111705] problems with re.py and regex.py Message-ID: <200008111919.MAA03524@delerium.i.sourceforge.net> Bug #111705, was updated on 2000-Aug-11 12:19 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Summary: problems with re.py and regex.py Details: Hi, here is something I have been working on for quite some time. I always thought it was my regex syntax, but I was incorrect. I tried it in perl, and php, and both worked fine. re.py has a problem with ([_a-zA-Z0-9-]\.*) where it hangs during compilation. regex.py has a problem with ([a-zA-Z]){2,3} (or any other similar statement) where it does not limit the number of characters properly. Here is the code ... import string import sys import regex def testemailaddr(emailaddr): pattern = regex.compile('^([_a-zA-Z0-9-]\.*){3,255}@([_a-zA-Z0-9-]\.*){3,255}\.([a-zA-Z]){2,3}$') if pattern.match(emailaddr) != None: valid = [1, emailaddr] else: valid = [0, emailaddr] return valid validemail = testemailaddr(sys.argv[1]) if validemail[0] == 1: print validemail[1], "is valid." else: print validemail[1], "is not valid." For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111705&group_id=5470 From noreply@sourceforge.net Fri Aug 11 21:25:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 13:25:46 -0700 Subject: [Python-bugs-list] [Bug #111710] socket.send() can do partial writes on some systems. Message-ID: <200008112025.NAA22581@bush.i.sourceforge.net> Bug #111710, was updated on 2000-Aug-11 13:25 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: socket.send() can do partial writes on some systems. Details: 0811 15:57 chronis:~% uname -a FreeBSD chronis.pobox.com 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Mar 21 01:05:14 EST 2000 root@chronis.pobox.com:/usr/src/sys/compile/MYBSD i386 0811 15:57 chronis:~% 0811 15:57 chronis:~% cat scratch/sendtstsrv.py import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind("chronis.pobox.com", 8010) while 1: s.listen(1) conn, addr = s.accept() print "connected from", addr while 1: data = conn.recv(1024) if not data: break print "done" conn.close() 0811 15:58 chronis:~% python scratch/sendtstsrv.py & [2] 76562 0811 15:58 chronis:~% cat scratch/sendtst.py #!/usr/bin/env python s = "0" * 10000000 import socket sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect("chronis.pobox.com", 8010) sent = sock.send(s) if sent != len(s): print "sent %d/%d chars" % (sent, len(s)) else: print "sent all chars" 0811 15:58 chronis:~% python !$ python scratch/sendtst.py connected from ('208.210.124.49', 1258) sent 17520/10000000 chars done 0811 15:58 chronis:~% NOTE: there is nothing in any man page for send() under linux (RH 6.1), Solaris (SunOS 5.5.1), OSF1 V4.0, or FreeBSD{3,4} that states that send() must not perform a partial write, though of those systems, it only seems to reproducibly do partial writes under FreeBSD4.0 Stable. Additionally, W.Richard Stevens' Unix Network Programming Vol 1, second edition states that """ A read or write on a stream socket might input or output fewer bytes than requested, but this is not an error condition.""" (page 77). Later, Stevens says of send() and recv() "These two functions are similar to the standard read and write functions, but one additional argument is required". (page 354). scott For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111710&group_id=5470 From noreply@sourceforge.net Fri Aug 11 23:30:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 11 Aug 2000 15:30:02 -0700 Subject: [Python-bugs-list] [Bug #111725] Response to bug 110619 Message-ID: <200008112230.PAA10193@delerium.i.sourceforge.net> Bug #111725, was updated on 2000-Aug-11 15:30 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Response to bug 110619 Details: It probably should be documented somewhere that for urllib, proxies will not work in the environment variable http_proxy The code looks at http://usr:pwd@com:8080 and parses the pwd@com:8080 as a port number and fails. It also ignores the proxy details here. If the proxy details are put into the url, as argument to urlopen, they still don't work, although they are parsed correctly. I'm behind a firewall and this bugged me for some time, as I always received a http error code of 407. Afyter some research of the protocol, etc. I finally resolved it by modifying urllib in the open_http method and changed the line: if auth: h.putheader('Authorization',... to if auth: h.putheader('Proxy-Authorization',... and it worked! Needless to say, whatever aspect of the http protocol requires this to be 'Authorization' will of course now fail for my version of urllib, but at least the proxy part functions correctly. Sorry I can't give any better details as I am not an http guru, just fumbling along! Hope this helps. Cheers, Perry Faulkner (Perry.Faulkner@macquarie.com.au) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111725&group_id=5470 From noreply@sourceforge.net Sun Aug 13 09:36:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 01:36:40 -0700 Subject: [Python-bugs-list] [Bug #110832] urljoin() bug with odd no of '..' (PR#194) Message-ID: <200008130836.BAA03467@delerium.i.sourceforge.net> Bug #110832, was updated on 2000-Aug-01 14:13 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Feature Request Priority: 6 Summary: urljoin() bug with odd no of '..' (PR#194) Details: Jitterbug-Id: 194 Submitted-By: DrMalte@ddd.de Date: Sun, 30 Jan 2000 19:40:45 -0500 (EST) Version: 1.5.2 and 1.4 OS: Linux While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing . The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) ==================================================================== Audit trail: Mon Feb 07 12:35:35 2000 guido changed notes Mon Feb 07 12:35:35 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:13 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Date: Mon, 31 Jan 2000 12:28:55 -0500 Thanks for your bug report and fix. I agree with your diagnosis. Would you please be so kind as to resend your patch with the legal disclaimer from http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: none Comment: Patch being considered. ------------------------------------------------------- Date: 2000-Aug-13 01:36 By: moshez Comment: OK, Jeremy -- this one is yours. Either notabug it, or check in the relevant patch (101064 -- assigned to you) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110832&group_id=5470 From noreply@sourceforge.net Sun Aug 13 18:05:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 10:05:49 -0700 Subject: [Python-bugs-list] [Bug #111802] anydbm cannot verify shelve database type Message-ID: <200008131705.KAA20495@delerium.i.sourceforge.net> Bug #111802, was updated on 2000-Aug-13 10:05 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Trash Priority: 5 Summary: anydbm cannot verify shelve database type Details: When opening an existing "shelve" database file. An exception is raised from anydbm saying "the database type could not be determined". For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111802&group_id=5470 From Dan@Grassi.org Sun Aug 13 22:20:40 2000 From: Dan@Grassi.org (Dan@Grassi.org) Date: Sun, 13 Aug 2000 17:20:40 -0400 (EDT) Subject: [Python-bugs-list] IDLE (PR#429) Message-ID: <20000813212040.1BE0B1CD71@dinsdale.python.org> Full_Name: Daniel Grassi Version: 1.5.2 OS: Linux Submission from: adsl-78-192-232.mia.bellsouth.net (216.78.192.232) IDLE would be _much_ more usefull is some/any installation instructions were provided! Yeah, they are no fun to write but what's the point of writing the code if it can't be installed and if it can't be installed it can't be USED! Hey, saying: "Here's a tarball" just doesn't cut it. Dan From noreply@sourceforge.net Mon Aug 14 01:25:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 17:25:35 -0700 Subject: [Python-bugs-list] [Bug #111818] .../test/test_fork1 hangs Message-ID: <200008140025.RAA18964@bush.i.sourceforge.net> Bug #111818, was updated on 2000-Aug-13 17:25 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: .../test/test_fork1 hangs Details: .../test/test_fork1 never terminates on Python1.6b1 which runs on RedHat Linux: uname -a gives Linux pclab55.research.bell-labs.com 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown gcc 2.91.66 OPT set to -O -g (also with -O2 -g) configuration is --with-thread --prefix=/u/gpkdata/Linux An identically compuled system (except gcc 2.95.1 ) on Solaris 2.6 operates properly. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111818&group_id=5470 From success@tfnisp.com Mon Aug 14 01:28:29 2000 From: success@tfnisp.com (success@tfnisp.com) Date: Sun, 13 Aug 2000 20:28:29 -0400 (EDT) Subject: [Python-bugs-list] Your Boat has arrived! (PR#430) Message-ID: <20000814002829.221AB1CD18@dinsdale.python.org> Thousands of people around the country have found Financial Relief by building their very own Home Based Business right out of their living rooms without spending a dime. The Company is called The Free Network and they are giving people across the country their very own businesses for FREE!! That's right for FREE!! There is no catch. No commitments. The Free Network understands that life today is not easy. They also know that many people want their own businesses but lack the resources to do so. They have solved the problem for you. All you need to do is take advantage of it. You can own your own Internet Company, Paging Company, Long Distance Company, Wireless Company or your own Virtuall Mall, ALL FOR FREE!! You are invited to review an opportunity that is changing the pace of online business...and it's FREE! How would you like to get paid every time someone visits your online mall and makes a purchase...and we'll give you your own online mall for FREE! View an online presentation now! http://dev.www.earnware.com/createweb/buzz/ To find out more information or to speak to a live person email your name and number and we will get back to you. At the Free Network, We want you to succeed! Our reputation is on the line. Visit our Website and take a look for yourself. http://www.thefreenetwork.com/summit Remember, this offer is FREE! Please accept our deepest apologies, if you received this email unsolicited, and you can be removed automatically below. *********** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:sszewczuk@tfnmail.com/?subject=REMOVE From noreply@sourceforge.net Mon Aug 14 03:50:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 19:50:58 -0700 Subject: [Python-bugs-list] [Bug #111520] Some "Very High Level" functions aren't Message-ID: <200008140250.TAA23531@bush.i.sourceforge.net> Bug #111520, was updated on 2000-Aug-09 14:22 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: Some "Very High Level" functions aren't Details: The so-called "Very High Level" functions in the Python C API that take FILE * arguments will not work in a multi-compiler environment; each compiler's notion of a struct FILE will be different. From an implementation standpoint these are very _low_ level functions. The Python documentation for these functions, and the "Extending and embedding" documentation, should make note of this potential problem. BTW, there are situations in which a compiler other than the compiler used to compile Python will be used. Please don't try to make this bug go away by requiring the same compiler be used as was used to compile Python. Edward Follow-Ups: Date: 2000-Aug-13 19:50 By: fdrake Comment: Added advisory material in Doc/api/api.tex revision 1.77. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111520&group_id=5470 From noreply@sourceforge.net Mon Aug 14 05:13:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 21:13:43 -0700 Subject: [Python-bugs-list] [Bug #110638] Invalid use of PyMem_DEL (PR#295) Message-ID: <200008140413.VAA26228@bush.i.sourceforge.net> Bug #110638, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 6 Summary: Invalid use of PyMem_DEL (PR#295) Details: Jitterbug-Id: 295 Submitted-By: niels@endea.demon.nl Date: Thu, 13 Apr 2000 14:16:25 -0400 (EDT) Version: 1.5.2 and 1.6.a2 OS: Win95 and Linux Hi, I ran into a bug while running a regrtest on 1.6a2 with debugging on. This produced a reference checking problem, which I now see is the same as reported in #113. I have tracked this down to the use of PyMem_DEL on an object created by PyObject_NEW in PyPcre_compile. When the compile fails, the new object is deallocated, but not removed from the reference chain. This also happens in 1.5.2. With a little grepping, I tracked down a few instances of this problem: pcremodule.c:PyPcre_compile unicodeobject.c:_PyUnicode_New socketmodule.c:newSSLObject threadmodule.c:newlockobject In each case a partially constructed, but already registered object is simply deleted without calling _Py_ForgetReference. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110638&group_id=5470 From noreply@sourceforge.net Mon Aug 14 05:22:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 21:22:40 -0700 Subject: [Python-bugs-list] [Bug #110855] test_array.py fails (PR#143) Message-ID: <200008140422.VAA26528@bush.i.sourceforge.net> Bug #110855, was updated on 2000-Aug-01 14:37 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Irreproducible Priority: 5 Summary: test_array.py fails (PR#143) Details: Jitterbug-Id: 143 Submitted-By: ellement@sdd.hp.com Date: Thu, 2 Dec 1999 14:04:38 -0500 (EST) Version: 1.5.2 OS: HP-UX 10.20 After building python, 'make test' fails when test_array is run: > python Lib/test/test_array.py Traceback (innermost last): File "Lib/test/test_array.py", line 85, in ? main() File "Lib/test/test_array.py", line 10, in main testtype('c', 'c') File "Lib/test/test_array.py", line 21, in testtype a.append(example) AttributeError: '' object has no attribute 'append' Memory fault(coredump) How do I go about debugging this? ==================================================================== Audit trail: Fri Dec 03 10:38:53 1999 guido changed notes Fri Dec 03 10:38:53 1999 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:37 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] test_array.py fails (PR#143) Date: Thu, 02 Dec 1999 14:07:32 -0500 > Full_Name: David Ellement > Version: 1.5.2 > OS: HP-UX 10.20 > Submission from: sanrel1.sdd.hp.com (192.6.114.30) > > > After building python, 'make test' fails when test_array is run: > > > python Lib/test/test_array.py > Traceback (innermost last): > File "Lib/test/test_array.py", line 85, in ? > main() > File "Lib/test/test_array.py", line 10, in main > testtype('c', 'c') > File "Lib/test/test_array.py", line 21, in testtype > a.append(example) > AttributeError: '' object has no attribute 'append' > Memory fault(coredump) > > > How do I go about debugging this? Seems like a pretty serious problem in your build. Use a debugger (e.g. gdb). The bugs list is not the forum to discuss this, since the bug is likely in your installation and not in Python. Try comp.lang.python for help. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:37 By: none Comment: Build problems? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110855&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:22:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:22:52 -0700 Subject: [Python-bugs-list] [Bug #110673] os.abspatth() error due to win32api.GetFullPathName (PR#380) Message-ID: <200008140622.XAA30506@bush.i.sourceforge.net> Bug #110673, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: os.abspatth() error due to win32api.GetFullPathName (PR#380) Details: Jitterbug-Id: 380 Submitted-By: 2jerry@writeme.com Date: Mon, 3 Jul 2000 17:14:02 -0400 (EDT) Version: 1.5.2 (win32api build 129) OS: pc win98 next to code: full_path_lst = map(os.path.abspath, sys.path) according to that sys.path include the source directory at the first place of sys.path. I noticed that if I call the module in its own directory (python -i module.py) the first item of sys.path is ''. That all ok: abspath function in os module call getcwd() function if path is Null. ... good day for UNIX like men (as me :)) ... but in NT or WIN 98 workstation: os.path.abspath call :win32api.GetFullPathName(path) in ntpath module and win32api.GetFullPathName('') return '' and not current directory. Maybe is it a functionality .. but is os-depend functionality available for a longtime ? Jerome.vacher alias Jerry the foolish dracomorpheus. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 16:19:30 +1000 Can anyone else here confirm that: a) os.abspath('') on Linux does indeed return the CWD. b) It is supposed to :-) If confirmed, this would be a bug in ntpath.py. It catches win32api exceptions, and returns the input name in that case. This would be triggered by: >>> win32api.GetFullPathName('') Traceback (most recent call last): File "", line 1, in ? pywintypes.api_error: (127, 'GetFullPathName', 'The specified procedure could not be found.') Is this indeed something we should fix? Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > 2jerry@writeme.com > Sent: Tuesday, 4 July 2000 7:14 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) > (PR#380) > > > Full_Name: Jerome VACHER > Version: 1.5.2 (win32api build 129) > OS: pc win98 > Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55) > > > next to code: > full_path_lst = map(os.path.abspath, sys.path) > > according to that sys.path include the source directory at the > first place of > sys.path. > > I noticed that if I call the module in its own directory (python > -i module.py) > the first item of sys.path is ''. > That all ok: abspath function in os module call getcwd() > function if path is > Null. > ... > good day for UNIX like men (as me :)) > ... > but in NT or WIN 98 workstation: > os.path.abspath call :win32api.GetFullPathName(path) in ntpath module > and > win32api.GetFullPathName('') return '' and not current directory. > > Maybe is it a functionality .. but is os-depend functionality > available for a > longtime ? > > Jerome.vacher alias Jerry the foolish dracomorpheus. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: "Fred L. Drake, Jr." Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 13:34:24 -0400 (EDT) Mark Hammond writes: > Can anyone else here confirm that: > > a) os.abspath('') on Linux does indeed return the CWD. Yes, that's right. > b) It is supposed to :-) I think that's the right thing to do. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member ------------------------------------------------------- Date: 2000-Aug-06 13:56 By: twouters Comment: Possibly already fixed, or at least Mark has looked at it :) ------------------------------------------------------- Date: 2000-Aug-06 15:55 By: mhammond Comment: This is not a bug in win32api.GetFullPathName(), but rather the use of GetFullPathName() to implement os.abspath(). Bug summary changed accordingly. Confirmed as a bug, and I will fix it! ------------------------------------------------------- Date: 2000-Aug-13 23:22 By: mhammond Comment: ntpath.py and test_ntpath.py checked in with the fix! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110673&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:22:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:22:10 -0700 Subject: [Python-bugs-list] [Bug #110673] os.abspatth() error due to win32api.GetFullPathName (PR#380) Message-ID: <200008140622.XAA30491@bush.i.sourceforge.net> Bug #110673, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: os.abspatth() error due to win32api.GetFullPathName (PR#380) Details: Jitterbug-Id: 380 Submitted-By: 2jerry@writeme.com Date: Mon, 3 Jul 2000 17:14:02 -0400 (EDT) Version: 1.5.2 (win32api build 129) OS: pc win98 next to code: full_path_lst = map(os.path.abspath, sys.path) according to that sys.path include the source directory at the first place of sys.path. I noticed that if I call the module in its own directory (python -i module.py) the first item of sys.path is ''. That all ok: abspath function in os module call getcwd() function if path is Null. ... good day for UNIX like men (as me :)) ... but in NT or WIN 98 workstation: os.path.abspath call :win32api.GetFullPathName(path) in ntpath module and win32api.GetFullPathName('') return '' and not current directory. Maybe is it a functionality .. but is os-depend functionality available for a longtime ? Jerome.vacher alias Jerry the foolish dracomorpheus. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 16:19:30 +1000 Can anyone else here confirm that: a) os.abspath('') on Linux does indeed return the CWD. b) It is supposed to :-) If confirmed, this would be a bug in ntpath.py. It catches win32api exceptions, and returns the input name in that case. This would be triggered by: >>> win32api.GetFullPathName('') Traceback (most recent call last): File "", line 1, in ? pywintypes.api_error: (127, 'GetFullPathName', 'The specified procedure could not be found.') Is this indeed something we should fix? Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > 2jerry@writeme.com > Sent: Tuesday, 4 July 2000 7:14 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] win32api.GetFullPathName (build 129) > (PR#380) > > > Full_Name: Jerome VACHER > Version: 1.5.2 (win32api build 129) > OS: pc win98 > Submission from: ppp-55.dialup-166.worldonline.fr (212.83.166.55) > > > next to code: > full_path_lst = map(os.path.abspath, sys.path) > > according to that sys.path include the source directory at the > first place of > sys.path. > > I noticed that if I call the module in its own directory (python > -i module.py) > the first item of sys.path is ''. > That all ok: abspath function in os module call getcwd() > function if path is > Null. > ... > good day for UNIX like men (as me :)) > ... > but in NT or WIN 98 workstation: > os.path.abspath call :win32api.GetFullPathName(path) in ntpath module > and > win32api.GetFullPathName('') return '' and not current directory. > > Maybe is it a functionality .. but is os-depend functionality > available for a > longtime ? > > Jerome.vacher alias Jerry the foolish dracomorpheus. > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list ------------------------------------------------------- Date: 2000-Aug-01 14:01 By: none Comment: From: "Fred L. Drake, Jr." Subject: RE: [Python-bugs-list] win32api.GetFullPathName (build 129) (PR#380) Date: Tue, 4 Jul 2000 13:34:24 -0400 (EDT) Mark Hammond writes: > Can anyone else here confirm that: > > a) os.abspath('') on Linux does indeed return the CWD. Yes, that's right. > b) It is supposed to :-) I think that's the right thing to do. -Fred -- Fred L. Drake, Jr. BeOpen PythonLabs Team Member ------------------------------------------------------- Date: 2000-Aug-06 13:56 By: twouters Comment: Possibly already fixed, or at least Mark has looked at it :) ------------------------------------------------------- Date: 2000-Aug-06 15:55 By: mhammond Comment: This is not a bug in win32api.GetFullPathName(), but rather the use of GetFullPathName() to implement os.abspath(). Bug summary changed accordingly. Confirmed as a bug, and I will fix it! ------------------------------------------------------- Date: 2000-Aug-13 23:22 By: mhammond Comment: ntpath.py and test_ntpath.py checked in with the fix! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110673&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:31:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:31:34 -0700 Subject: [Python-bugs-list] [Bug #110601] expert on extension modules and multiple interpreters? (PR#125) Message-ID: <200008140631.XAA30801@bush.i.sourceforge.net> Bug #110601, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: expert on extension modules and multiple interpreters? (PR#125) Details: Jitterbug-Id: 125 Submitted-By: Nikolas Kauer Date: Tue, 9 Nov 1999 18:43:09 -0600 (CST) Version: None OS: None Dear Guido, (please read first paragraph) I discovered a Python problem that so far nobody could really explain, since a precise explanation requires in-depth knowledge about the internals of the Python interpreter. I HAVE DONE MY HOMEWORK and have posted this message to various mailing lists including comp.lang.python, python-help@python.org and pyapache-devel@msg.com.mx and communicated with several people individually, getting some guesses (appended after the problem description), but no competent answer, yet. I'm sure you know somebody who could provide that answer, and would appreciate it if you could FORWARD THIS MESSAGE to such a person. Best regards, Nikolas PS I'm sure you heard this a thousand times, nevertheless I like Python and enjoy programming in Python. I think it's a beautifully designed programming language. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I run the following test script on Apache-1.3.6/PyApache-4.19 on Linux 2.2.5 (RedHat 6.0) with only one httpd child and the module mxDateTime compiled into Python/PyApache, so there is no dynamic loading of a shared library. ------------------------------------------------------------ print "Content-type: text/plain" print print import sys, traceback # just checking ... if not sys.modules.has_key('mxDateTime'): print 'No module mxDateTime in sys.modules' print import mxDateTime print "sys.modules['mxDateTime'] = ", sys.modules['mxDateTime'] print "mxDateTime.__dict__['now'] = ", mxDateTime.__dict__['now'] print print "calling mxDateTime.now() gives:", try: print mxDateTime.now() except: print traceback.print_exc(file=sys.stdout) -------------------------------------------------------------- First time http://localhost/mytest.py gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = mxDateTime.__dict__['now'] = calling mxDateTime.now() gives: 1999-10-28 18:28:49.75 ******************************* And again http://localhost/mytest.py now gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = mxDateTime.__dict__['now'] = calling mxDateTime.now() gives: Traceback (innermost last): File "/local/web/alpha/docroot/mytest.py", line 16, in ? print mxDateTime.now() TypeError: call of non-function (type None) ******************************* After that experience, I eliminated all dependencies on module DateTime/mxDateTime in my Python code, but now I get the same error whenever something in module MySQLdb is accessed for the second time ... The mxDateTime author Marc Lemburg writes: "[...] indicates that PyApache (or perhaps the Python finalizer) has cleared the module's namespace... which is bad, since extension modules can typically only initialize themselves *once*." Marc writes further: "[T]his is really odd: the 'now' symbol still refers to the existing function while the module seems to return None as attribute." The PyApache coordinator Lele Gaifax writes: "I can confirm that the problem lives in the cleanup mechanism. Python clears up its dictionaries, and doesn't allow a reinit, as Marc pointed out. This is not a PyApache fault: you can get the very same result running the pysrv demo [...]. In fact, every use of such modules mixed to multiple interpreters should cause the problem." Apparently, the fact that a module works with regular Python does not guarantee that it also works with PyApache (or pysrv). Lele Gaifax writes: "[...]I cannot see a way out, if not digging in Python's internals. [D]oes someone know if the problem has been raised before in the Python community?" Please, could someone with Python internals expertise explain this issue? How can I tell in advance if an extension module will work with PyApache? Is it possible to trick Python into cleanly re-initializing a module? Is there any hope that I can run my existing Web site with the Python interpreter embedded into Apache's httpd? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ More insights from this past week: Lele Gaifax writes: "Well, I seems to have tracked it down to the cache you use on Python's time module. I changed the function mxDateTime_now, where's the only reference to that module, to use `PyImport_AddModule ("time")' instead and extracting the dictionary from its result instead from Python_time_module, that I left alone. That function returns a borrowed reference to the module object, *provided* it is already loaded. Since this is done at mxDateTime's initialization, this is probably safe, but it needs to be checked... Anyway, so patched the module does not break PyApache, [...]" Marc Lemburg replies: "That's interesting: the time module's namespace is probably cleared during the Fini code stage. This would change the interpretation of the error. What you see is the error produced by the internals of the now() function and not related to the mxDateTime module namespace itself. Since time.time is the only function I really use from the Python time module perhaps caching only the function would do the trick. BTW, when finalization occurrs, is mxDateTime_Cleanup() being called ? It should reset the global reference to the time module (at least that's what my current code does): [code] Something else I could do is move time module lookup from the initmxDateTime() function into now() itself in case that helps. [...] I would guess that the setup mxODBC + mxDateTime has the same problems related to mxODBC holding a reference to mxDateTime." Any help in form of diagnostics, explanations and suggestions would be greatly appreciated. Nikolas ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some ideas from python-help@python.org: Mark Hammond writes: "If I understand the problem correct, it is simply that Python can not handle multiple Py_Init()/Py_Finalize() calls. Doing a Py_Finalize() cleans things up, but another Py_Init() can not restore everything back to a working state. I agree this is a problem, and it has ben brought up before. I suffer the same problem with the COM extensions. Ideally this needs to be fixed properly, but it is not trivial to do so - the entire module init process would need to be re-thought. The only solution I can think of is to get Apache to never finalize Python. Of course, I may be completely off-track here..." Martin von Loewis writes: "I think the problem is different. PyApache does *not* invoke Py_Finalize(*), but Py_EndInterpreter. This does PyImport_Cleanup, then PyInterpreterState_Delete. This is where I got stuck: The PyImport_Cleanup iterates over the interpreter-state's module list, which is then cleared, and completely discarded. I did not actually find the place where state is preserved across interpreters, so the problem can't possibly happen :-> (*) Of course, Apache eventually does Py_Finalize, when the whole server is shut down. Each individual CGI only goes through Py_NewInterpreter/Py_EndInterpreter." ==================================================================== Audit trail: Fri Dec 03 10:21:06 1999 guido changed notes Fri Dec 03 10:21:07 1999 guido moved from incoming to open Fri Dec 03 10:21:47 1999 guido changed notes Follow-Ups: Date: 2000-Aug-13 23:31 By: mhammond Comment: Assigning to MAL - it involves mxODBC and Apache on a Linux box, so surely he is more qualified :-) I'm inclined to mark this is irreproducible, but maybe Marc has had further insights. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:37:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:37:33 -0700 Subject: [Python-bugs-list] [Bug #110622] pdb bug (PR#236) Message-ID: <200008140637.XAA30971@bush.i.sourceforge.net> Bug #110622, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: Works For Me Bug Group: Irreproducible Priority: 5 Summary: pdb bug (PR#236) Details: Jitterbug-Id: 236 Submitted-By: jsolbrig@webcom.com Date: Tue, 14 Mar 2000 19:55:22 -0500 (EST) Version: 1.5.2 OS: Win32/win95 pdb (python debugger) tends to drop (ignore) breaks in multi-file debugging. I wish I had time to isolate the offending code but I don't. ==================================================================== Audit trail: Mon May 22 17:37:26 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-13 23:37 By: mhammond Comment: I've done extensive work with bdb and pdb, and never seen this. I believe we can close this as irreproducible, and I will in a few days unless someone screams or describes a reproduction scenario. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110622&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:39:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:39:52 -0700 Subject: [Python-bugs-list] [Bug #110631] Debugger (win and idle) (PR#283) Message-ID: <200008140639.XAA31008@bush.i.sourceforge.net> Bug #110631, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 3 Summary: Debugger (win and idle) (PR#283) Details: Jitterbug-Id: 283 Submitted-By: musingattheruins@yahoo.com Date: Mon, 10 Apr 2000 12:30:44 -0400 (EDT) Version: 1.5.2 OS: Win32 The python debugger (both Idle and PythonWin) does not undertand packages. Can run scripts from the command line that cannot be run in the debugger... Create package 'Test' in the directory "My Modules", add an __init__.py (empty) to the directory "My modules\Test", create file testfile.py with the contents... class TheTest: def __init__(self): self.i = 1 def go(self): return self.i Add the path to the Python path with the following file (test.reg)... REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\1.5\PythonPath\TheTest] @="C:\\My modules" then try the following at the python prompt: import Test.testfile j = Test.testfile.TheTest() k = j.go runs fine right? Yes it does, now step through it in the debugger and you get... import Test.testfile j = Test.testfile.TheTest() #exception: attribute 'TheTest' k = j.go Does not appear to be realted to the class (you can change it to a 'function in a module' instead of a 'method in a class in a module' and you get the a similar result.) Debugger does not understand packages. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110631&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:42:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:42:31 -0700 Subject: [Python-bugs-list] [Bug #110637] ihooks on windows and pythoncom (PR#294) Message-ID: <200008140642.XAA31135@bush.i.sourceforge.net> Bug #110637, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: ihooks on windows and pythoncom (PR#294) Details: Jitterbug-Id: 294 Submitted-By: mak@mikroplan.com.pl Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT) Version: cvs OS: windows Hi, Python module ihooks is not so compatible with builtin imp while importing modules whose name is stored in registry eg. pythoncom/pywintypes. import ihooks ihooks.install() import pythoncom This code will fail inside pythonwin ide too ! ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-13 23:42 By: mhammond Comment: This needs a resolution. The "registered module" code in the code also needs to support HKEY_CURRENT_USER along with the HKEY_LOCAL_MACHINE it does now. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110637&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:44:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:44:02 -0700 Subject: [Python-bugs-list] [Bug #110642] freeze with "-s service" and "-m" (PR#315) Message-ID: <200008140644.XAA31157@bush.i.sourceforge.net> Bug #110642, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: freeze with "-s service" and "-m" (PR#315) Details: Jitterbug-Id: 315 Submitted-By: tdickenson@geminidataloggers.com Date: Fri, 5 May 2000 05:50:37 -0400 (EDT) Version: 1.5.2 OS: Windows There is a problem with combining two different options to freeze. Those options are: 1. "-s service" indicating that the frozen program is a windows service. one effect of this is that the myscript.py file on the freeze command line should be available for import, not as __main__ 2. "-m" indicating that extra modules are to be included in the freeze. The relevant block of code is at line 335... # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: if modargs: mf.import_hook(scriptfile) else: mf.load_file(scriptfile) For a service, the outer 'else' block is entered. If -m is not specified then the inner 'else' block is entered. mf.load_file assumes its parameter is a filename (to be imported from), an everything is happy. If -m is specified then the inner 'if' block is entered. mf.import_hook assumes its parameter is a module to imported. This fails because "myscript.py" is not a module name, and can not be imported. I think this block of code was naively copy/pasted from the block above it (where it correctly implements the -m option), and never tested with the -m option. This block (starting line 335) should be replaced with # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: mf.load_file(scriptfile) I have tested this patch on windows, freezing service and non-service scripts, both with and without -m ==================================================================== Audit trail: Mon May 22 17:28:43 2000 guido changed notes Mon May 22 17:28:43 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:10 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] freeze with "-s service" and "-m" (PR#315) Date: Fri, 5 May 2000 23:19:14 +1000 > I think this block of code was naively copy/pasted from the > block above it Quite likely! > This block (starting line 335) should be replaced with ... If you submit a patch to this effect (to the patches address), I would be happy to bless it (and given that the service code is mine, I guess that would be all that is needed...) Thanks, Mark. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110642&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:45:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:45:34 -0700 Subject: [Python-bugs-list] [Bug #110670] Win32 os.listdir raises confusing errors (PR#374) Message-ID: <200008140645.XAA31173@bush.i.sourceforge.net> Bug #110670, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Win32 os.listdir raises confusing errors (PR#374) Details: Jitterbug-Id: 374 Submitted-By: tpeters@beopen.com Date: Thu, 29 Jun 2000 02:25:18 -0400 (EDT) Version: 1.6a2 OS: Windows Copying this over from the SourceForge bug manager: https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=108381 Here's the original complaint: On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Here's confirmation under Win98 1.6a2: C:\Python16>python Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> os.listdir('/cow') Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 3] No such process: '/cow' >>> ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110670&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:47:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:47:24 -0700 Subject: [Python-bugs-list] [Bug #110682] pdb can only step when at botframe (PR#4) Message-ID: <200008140647.XAA31296@bush.i.sourceforge.net> Bug #110682, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: Later Bug Group: None Priority: 3 Summary: pdb can only step when at botframe (PR#4) Details: Jitterbug-Id: 4 Submitted-By: MHammond@skippinet.com.au Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT) Version: 1.5.2 OS: Windows [Resubmitted by GvR] It is a problem that bugged me for _ages_. Since the years I first wrote the Pythonwin debugger Ive learnt alot about how it works :-) The problem is simply: when the frame being debugged is self.botframe, it is impossible to continue - only "step" works. A "continue" command functions as a step until you start debugging a frame below self.botframe. It is less of a problem with pdb, but makes a GUI debugger clunky - if you start a debug session by stepping into a module, the "go" command seems broken. The simplest way to demonstrate the problem is to create a module, and add a "pdb.set_trace()" statement at the top_level (ie, at indent level 0). You will not be able to "continue" until you enter a function. My solution was this: instead of run() calling "exec" directly, it calls another internal function. This internal function contains a single line - the "exec", and therefore never needs to be debugged directly. Then stop_here is modified accordingly. The end result is that "self.botframe" becomes an "intermediate" frame, and is never actually stopped at - ie, self.botframe effectivly becomes one frame _below_ the bottom frame the user is interested in. Im not yet trying to propose a patch, just to discuss this and see if the "right thing" can be determined and put into pdb. Thanks, Mark. ==================================================================== Audit trail: Mon Jul 12 15:39:35 1999 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110682&group_id=5470 From noreply@sourceforge.net Mon Aug 14 07:51:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 13 Aug 2000 23:51:41 -0700 Subject: [Python-bugs-list] [Bug #110699] redirected stdout under Windows NT (PR#165) Message-ID: <200008140651.XAA31454@bush.i.sourceforge.net> Bug #110699, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Wont Fix Bug Group: Not a Bug Priority: 5 Summary: redirected stdout under Windows NT (PR#165) Details: Jitterbug-Id: 165 Submitted-By: xxx-bad@juno.com Date: Tue, 21 Dec 1999 11:43:08 -0500 (EST) Version: 1.5.2 OS: Win NT 4.0, SP4 Hello, I have troubles running Python scripts from command line. The script print "Hello" works fine if ran as test.py However, if I run it as test.py >test.txt The test.txt is empty (0 bytes), and no console output. I did not see similar behavior in 95. In addition, sys.stdout.fileno() is -1 for redirected file which does not look right. Thank you, Vadim ==================================================================== Audit trail: Tue Dec 21 11:46:47 1999 guido changed notes Tue Dec 21 11:46:47 1999 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] redirected stdout under Windows NT (PR#165) Date: Tue, 21 Dec 1999 11:47:12 -0500 > I have troubles running Python scripts from command line. The script > > print "Hello" > > works fine if ran as > > test.py > > However, if I run it as > > test.py >test.txt > > The test.txt is empty (0 bytes), and no console output. > > I did not see similar behavior in 95. > > In addition, sys.stdout.fileno() is -1 for redirected file which does not look > right. This is a problem in Windows -- I/O redirection doesn't always work as expected, depending on how your script is invoked. See Python FAQ 8.14 for various work-arounds: http://www.python.org/cgi-bin/faqw.py?req=show&file=faq08.014.htp --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] redirected stdout under Windows NT (PR#165) Date: Wed, 22 Dec 1999 09:54:22 +1100 This is a bug in Windows NT, not in Python. The exact same thing happens with Perl and all other command line programs. The solution is to always prefix the name of the .py file with the name of the Python executable. Eg: foo.py > foo # Will not work python.exe foo.py > foo # will work. This is a bug in Windows NT, but has apparently been fixed in Windows 2000. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of xxx-bad@juno.com > Sent: Wednesday, 22 December 1999 3:43 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] redirected stdout under Windows NT (PR#165) > > > Full_Name: Vadim Suvorov > Version: 1.5.2 > OS: Win NT 4.0, SP4 > Submission from: internet1.compressorcontrols.com (165.90.228.92) > > > Hello, > > I have troubles running Python scripts from command line. The script > > print "Hello" > > works fine if ran as > > test.py > > However, if I run it as > > test.py >test.txt > > The test.txt is empty (0 bytes), and no console output. > > I did not see similar behavior in 95. > > In addition, sys.stdout.fileno() is -1 for redirected file which > does not look > right. > > Thank you, > > Vadim > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: See FAQ 8.14. ------------------------------------------------------- Date: 2000-Aug-13 23:51 By: mhammond Comment: As the comments indicate, this is a well known bug in Windows, not in Python. Setting to "Not a Bug", and closing. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110699&group_id=5470 From noreply@sourceforge.net Mon Aug 14 11:31:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 03:31:29 -0700 Subject: [Python-bugs-list] [Bug #110601] expert on extension modules and multiple interpreters? (PR#125) Message-ID: <200008141031.DAA22174@delerium.i.sourceforge.net> Bug #110601, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: expert on extension modules and multiple interpreters? (PR#125) Details: Jitterbug-Id: 125 Submitted-By: Nikolas Kauer Date: Tue, 9 Nov 1999 18:43:09 -0600 (CST) Version: None OS: None Dear Guido, (please read first paragraph) I discovered a Python problem that so far nobody could really explain, since a precise explanation requires in-depth knowledge about the internals of the Python interpreter. I HAVE DONE MY HOMEWORK and have posted this message to various mailing lists including comp.lang.python, python-help@python.org and pyapache-devel@msg.com.mx and communicated with several people individually, getting some guesses (appended after the problem description), but no competent answer, yet. I'm sure you know somebody who could provide that answer, and would appreciate it if you could FORWARD THIS MESSAGE to such a person. Best regards, Nikolas PS I'm sure you heard this a thousand times, nevertheless I like Python and enjoy programming in Python. I think it's a beautifully designed programming language. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I run the following test script on Apache-1.3.6/PyApache-4.19 on Linux 2.2.5 (RedHat 6.0) with only one httpd child and the module mxDateTime compiled into Python/PyApache, so there is no dynamic loading of a shared library. ------------------------------------------------------------ print "Content-type: text/plain" print print import sys, traceback # just checking ... if not sys.modules.has_key('mxDateTime'): print 'No module mxDateTime in sys.modules' print import mxDateTime print "sys.modules['mxDateTime'] = ", sys.modules['mxDateTime'] print "mxDateTime.__dict__['now'] = ", mxDateTime.__dict__['now'] print print "calling mxDateTime.now() gives:", try: print mxDateTime.now() except: print traceback.print_exc(file=sys.stdout) -------------------------------------------------------------- First time http://localhost/mytest.py gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = mxDateTime.__dict__['now'] = calling mxDateTime.now() gives: 1999-10-28 18:28:49.75 ******************************* And again http://localhost/mytest.py now gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = mxDateTime.__dict__['now'] = calling mxDateTime.now() gives: Traceback (innermost last): File "/local/web/alpha/docroot/mytest.py", line 16, in ? print mxDateTime.now() TypeError: call of non-function (type None) ******************************* After that experience, I eliminated all dependencies on module DateTime/mxDateTime in my Python code, but now I get the same error whenever something in module MySQLdb is accessed for the second time ... The mxDateTime author Marc Lemburg writes: "[...] indicates that PyApache (or perhaps the Python finalizer) has cleared the module's namespace... which is bad, since extension modules can typically only initialize themselves *once*." Marc writes further: "[T]his is really odd: the 'now' symbol still refers to the existing function while the module seems to return None as attribute." The PyApache coordinator Lele Gaifax writes: "I can confirm that the problem lives in the cleanup mechanism. Python clears up its dictionaries, and doesn't allow a reinit, as Marc pointed out. This is not a PyApache fault: you can get the very same result running the pysrv demo [...]. In fact, every use of such modules mixed to multiple interpreters should cause the problem." Apparently, the fact that a module works with regular Python does not guarantee that it also works with PyApache (or pysrv). Lele Gaifax writes: "[...]I cannot see a way out, if not digging in Python's internals. [D]oes someone know if the problem has been raised before in the Python community?" Please, could someone with Python internals expertise explain this issue? How can I tell in advance if an extension module will work with PyApache? Is it possible to trick Python into cleanly re-initializing a module? Is there any hope that I can run my existing Web site with the Python interpreter embedded into Apache's httpd? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ More insights from this past week: Lele Gaifax writes: "Well, I seems to have tracked it down to the cache you use on Python's time module. I changed the function mxDateTime_now, where's the only reference to that module, to use `PyImport_AddModule ("time")' instead and extracting the dictionary from its result instead from Python_time_module, that I left alone. That function returns a borrowed reference to the module object, *provided* it is already loaded. Since this is done at mxDateTime's initialization, this is probably safe, but it needs to be checked... Anyway, so patched the module does not break PyApache, [...]" Marc Lemburg replies: "That's interesting: the time module's namespace is probably cleared during the Fini code stage. This would change the interpretation of the error. What you see is the error produced by the internals of the now() function and not related to the mxDateTime module namespace itself. Since time.time is the only function I really use from the Python time module perhaps caching only the function would do the trick. BTW, when finalization occurrs, is mxDateTime_Cleanup() being called ? It should reset the global reference to the time module (at least that's what my current code does): [code] Something else I could do is move time module lookup from the initmxDateTime() function into now() itself in case that helps. [...] I would guess that the setup mxODBC + mxDateTime has the same problems related to mxODBC holding a reference to mxDateTime." Any help in form of diagnostics, explanations and suggestions would be greatly appreciated. Nikolas ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some ideas from python-help@python.org: Mark Hammond writes: "If I understand the problem correct, it is simply that Python can not handle multiple Py_Init()/Py_Finalize() calls. Doing a Py_Finalize() cleans things up, but another Py_Init() can not restore everything back to a working state. I agree this is a problem, and it has ben brought up before. I suffer the same problem with the COM extensions. Ideally this needs to be fixed properly, but it is not trivial to do so - the entire module init process would need to be re-thought. The only solution I can think of is to get Apache to never finalize Python. Of course, I may be completely off-track here..." Martin von Loewis writes: "I think the problem is different. PyApache does *not* invoke Py_Finalize(*), but Py_EndInterpreter. This does PyImport_Cleanup, then PyInterpreterState_Delete. This is where I got stuck: The PyImport_Cleanup iterates over the interpreter-state's module list, which is then cleared, and completely discarded. I did not actually find the place where state is preserved across interpreters, so the problem can't possibly happen :-> (*) Of course, Apache eventually does Py_Finalize, when the whole server is shut down. Each individual CGI only goes through Py_NewInterpreter/Py_EndInterpreter." ==================================================================== Audit trail: Fri Dec 03 10:21:06 1999 guido changed notes Fri Dec 03 10:21:07 1999 guido moved from incoming to open Fri Dec 03 10:21:47 1999 guido changed notes Follow-Ups: Date: 2000-Aug-13 23:31 By: mhammond Comment: Assigning to MAL - it involves mxODBC and Apache on a Linux box, so surely he is more qualified :-) I'm inclined to mark this is irreproducible, but maybe Marc has had further insights. ------------------------------------------------------- Date: 2000-Aug-14 03:31 By: lemburg Comment: The problem you describe is an artifact of the way mxDateTime tries to reuse the time.time() API available through the standard Python time module. I think I have fixed the problem in my latest version. If you're interested I can email you a pre-release copy to test it against PyApache. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470 From noreply@sourceforge.net Mon Aug 14 12:04:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 04:04:35 -0700 Subject: [Python-bugs-list] [Bug #111667] unicode core dump Message-ID: <200008141104.EAA07691@bush.i.sourceforge.net> Bug #111667, was updated on 2000-Aug-11 04:38 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: unicode core dump Details: This two-liner faults inside PyUnicode_EncodeRawUnicodeEscape >>> import cPickle >>> cPickle.dumps(u'') Follow-Ups: Date: 2000-Aug-11 05:42 By: lemburg Comment: On which platform do you get this seg fault ? FYI, I can reproduce it on Linux, but the gdb stack trace doesn't really show any hint as to what is failing... could be a compiler optimization bug. ------------------------------------------------------- Date: 2000-Aug-11 06:41 By: none Comment: Seen on RedHat 6.2 and NT. Its VC6 that gives the helpful call stack. Ive done a little digging - the failing scenario is: 1. PyUnicode_EncodeRawUnicodeEscape uses PyString_FromStringAndSize 2. Sometimes PyString_FromStringAndSize will return a non-unique string 3. PyUnicode_EncodeRawUnicodeEscape sometimes modifies the shared string, which is not good but not the cause of this problem. 4. _PyString_Resize will fail given a non-unique string. In this case it assigns NULL to the value pointed to by its first parameter. 5. The Py_DECREF just after the onError faults because its parameter is NULL ------------------------------------------------------- Date: 2000-Aug-14 04:04 By: lemburg Comment: Assigned to myself for better visibility. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111667&group_id=5470 From noreply@sourceforge.net Mon Aug 14 12:14:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 04:14:05 -0700 Subject: [Python-bugs-list] [Bug #111667] unicode core dump Message-ID: <200008141114.EAA07996@bush.i.sourceforge.net> Bug #111667, was updated on 2000-Aug-11 04:38 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: unicode core dump Details: This two-liner faults inside PyUnicode_EncodeRawUnicodeEscape >>> import cPickle >>> cPickle.dumps(u'') Follow-Ups: Date: 2000-Aug-11 05:42 By: lemburg Comment: On which platform do you get this seg fault ? FYI, I can reproduce it on Linux, but the gdb stack trace doesn't really show any hint as to what is failing... could be a compiler optimization bug. ------------------------------------------------------- Date: 2000-Aug-11 06:41 By: none Comment: Seen on RedHat 6.2 and NT. Its VC6 that gives the helpful call stack. Ive done a little digging - the failing scenario is: 1. PyUnicode_EncodeRawUnicodeEscape uses PyString_FromStringAndSize 2. Sometimes PyString_FromStringAndSize will return a non-unique string 3. PyUnicode_EncodeRawUnicodeEscape sometimes modifies the shared string, which is not good but not the cause of this problem. 4. _PyString_Resize will fail given a non-unique string. In this case it assigns NULL to the value pointed to by its first parameter. 5. The Py_DECREF just after the onError faults because its parameter is NULL ------------------------------------------------------- Date: 2000-Aug-14 04:04 By: lemburg Comment: Assigned to myself for better visibility. ------------------------------------------------------- Date: 2000-Aug-14 04:14 By: lemburg Comment: Thanks for the analysis. You are right: PyString_FromStringAndSize() will return a shared copy in case the size parameter is 0. _PyString_Resize() should probably include a check to prevent resizing shared strings, but for now I'll simply checkin a patch for the Unicode object which covers all instances of the problem. Thanks. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111667&group_id=5470 From noreply@sourceforge.net Mon Aug 14 12:29:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 04:29:21 -0700 Subject: [Python-bugs-list] [Bug #111667] unicode core dump Message-ID: <200008141129.EAA24187@delerium.i.sourceforge.net> Bug #111667, was updated on 2000-Aug-11 04:38 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: unicode core dump Details: This two-liner faults inside PyUnicode_EncodeRawUnicodeEscape >>> import cPickle >>> cPickle.dumps(u'') Follow-Ups: Date: 2000-Aug-11 05:42 By: lemburg Comment: On which platform do you get this seg fault ? FYI, I can reproduce it on Linux, but the gdb stack trace doesn't really show any hint as to what is failing... could be a compiler optimization bug. ------------------------------------------------------- Date: 2000-Aug-11 06:41 By: none Comment: Seen on RedHat 6.2 and NT. Its VC6 that gives the helpful call stack. Ive done a little digging - the failing scenario is: 1. PyUnicode_EncodeRawUnicodeEscape uses PyString_FromStringAndSize 2. Sometimes PyString_FromStringAndSize will return a non-unique string 3. PyUnicode_EncodeRawUnicodeEscape sometimes modifies the shared string, which is not good but not the cause of this problem. 4. _PyString_Resize will fail given a non-unique string. In this case it assigns NULL to the value pointed to by its first parameter. 5. The Py_DECREF just after the onError faults because its parameter is NULL ------------------------------------------------------- Date: 2000-Aug-14 04:04 By: lemburg Comment: Assigned to myself for better visibility. ------------------------------------------------------- Date: 2000-Aug-14 04:14 By: lemburg Comment: Thanks for the analysis. You are right: PyString_FromStringAndSize() will return a shared copy in case the size parameter is 0. _PyString_Resize() should probably include a check to prevent resizing shared strings, but for now I'll simply checkin a patch for the Unicode object which covers all instances of the problem. Thanks. ------------------------------------------------------- Date: 2000-Aug-14 04:29 By: lemburg Comment: Patch checked in. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111667&group_id=5470 From noreply@sourceforge.net Mon Aug 14 13:08:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 05:08:23 -0700 Subject: [Python-bugs-list] [Bug #111858] Python-1.6b1 uses _cursesmodule.so Message-ID: <200008141208.FAA09848@bush.i.sourceforge.net> Bug #111858, was updated on 2000-Aug-14 05:08 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Python-1.6b1 uses _cursesmodule.so Details: Compiling the curses module for Python-1.6b1 only after renaming cursesmodule.c to _cursesmodule.c in Modules/Setup. Moreover, this will result in building cursesmodule.so instead of _cursesmodule.so as expected by Lib/curses. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111858&group_id=5470 From noreply@sourceforge.net Mon Aug 14 13:51:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 05:51:20 -0700 Subject: [Python-bugs-list] [Bug #111860] file.writelines() crashes Message-ID: <200008141251.FAA27102@delerium.i.sourceforge.net> Bug #111860, was updated on 2000-Aug-14 05:51 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: file.writelines() crashes Details: writelines() method causes GPF when sequence with arbitrary objects passed as argument. Unicode character are written to file as '\0'. Python 1.6b1, NT4.0 For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111860&group_id=5470 From noreply@sourceforge.net Mon Aug 14 14:50:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 06:50:47 -0700 Subject: [Python-bugs-list] [Bug #110639] test_fork1 hangs with 1.6a2 on Linux (PR#296) Message-ID: <200008141350.GAA13373@bush.i.sourceforge.net> Bug #110639, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Works For Me Bug Group: 3rd Party Priority: 7 Summary: test_fork1 hangs with 1.6a2 on Linux (PR#296) Details: Jitterbug-Id: 296 Submitted-By: oli@andrich.net Date: Thu, 13 Apr 2000 15:18:07 -0400 (EDT) Version: 1.6a2 OS: Linux Mandrake 2.2.14-mdksmp Hi, I am currently evaluating Python 1.6 on my machine in order to be uptodate with the Linux distribution as soon as 1.6 final is released. The testsuite runs fine, just one test fails completely. test_fork1 When I run the test, it sometimes runs really fine (very seldom). Most of the time it hangs and uses nearly 100% of CPU time. The loop in the child prozess is completed successfully. n is 0 as it ought to be. But the os.waitpid call hangs for an indefinete time. This is strange, cause I can't reproduce this in an equivalent c code snippet. And without creation of the threads it works really fine and doesn't hang at all. Any idea? I am running a 2.2.14 Linux on a SMP machine (non SMP machine show the same behaviour). glibc 2.1.3. Bye, Oliver ==================================================================== Audit trail: Thu Apr 13 15:55:33 2000 fdrake sent reply 1 Thu Apr 13 15:55:45 2000 fdrake moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:09 By: none Comment: From: Fred L. Drake, Jr. Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu Apr 13 15:55:33 2000 Oliver, We're aware of it, but haven't figured out the exact problem yet. If you can provide additional information on the observed behavior, that would be good. I get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, and blocks. I'm suspecting a pthread implementation problem, but haven't had enough time to really dig into it sufficiently to be sure. -Fred ------------------------------------------------------- Date: 2000-Jul-31 14:09 By: none Comment: From: Oliver Andrich Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 22:26:08 +0200 Hi, well what I have discovered so far is. - Normal optimizations for Mandrake packages results in a sure segfault. - Normal python optimizations (jst calling make) causes hangs sometimes works. A look at ps ax shows, that there exist 6 active python "processes" (the parent process and 5 threads) and one defunct python process (the child). So thet child terminates correctly as I already mentioned. But the os.waitpid doesn't discover that the child has already exited. Things I will to tonight: - write a complete cversion of the testcode - compile python against another thread library - compile python against the most recent glibc snapshot - compile python on a RedHat 6.1 system Hopefully I get some more insights. Sadly, I am not good at c debugging, as I am a Python code by choice and a C coder who has written his last C code five years ago (a really program not just a Python extension ;-). Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred ------------------------------------------------------- Date: 2000-Jul-31 14:09 By: none Comment: From: Oliver Andrich Subject: Re: test_fork1 hangs with 1.6a2 on Linux (PR#296) Date: Thu, 13 Apr 2000 23:38:08 +0200 Hi, I just checked the following to things. I patched the threading to work with GNU pth and get the same results. When I run the test script with Python 1.5.2 on the same machine, that means same glibc and so on, it works fine. I compared the threading code of Python 1.5.2 and 1.6.a2 and it doesn't seem to differ at all. Same for the posixcode as far it is relevant for the test. I am a little bit irritated by this. Best regards, Oliver On Thu, Apr 13, 2000 at 03:55:34PM -0400, Fred@python.org wrote: > Oliver, > We're aware of it, but haven't figured out the exact problem yet. If you can > provide additional information on the observed behavior, that would be good. I > get three different behaviors on a Mandrake 7.1 SMP machine: works, segfaults, > and blocks. I'm suspecting a pthread implementation problem, but haven't had > enough time to really dig into it sufficiently to be sure. > > > -Fred ------------------------------------------------------- Date: 2000-Aug-11 06:49 By: fdrake Comment: I do not currently have ready access to an SMP machine, so I can't tell if this is fixed or not. I cannot reproduce this using a uniprocessor running Mandrake 7.1 (kernel 2.2.15-4mdk). This bug may also be related to the use of the GNU Pth pthreads implementation; we should find out which threading library was being used. ------------------------------------------------------- Date: 2000-Aug-14 06:50 By: fdrake Comment: This does not appear to be a problem in the currrent code base, and may be an artefact of using the GNU Pth thread library; I cannot reproduce this on either a single or dual processor machine. If you can still get this behavior from the CVS version of Python, please ask us to reopen this bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110639&group_id=5470 From noreply@sourceforge.net Mon Aug 14 15:21:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 07:21:40 -0700 Subject: [Python-bugs-list] [Bug #111866] Overflow Error Message-ID: <200008141421.HAA14635@bush.i.sourceforge.net> Bug #111866, was updated on 2000-Aug-14 07:21 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Overflow Error Details: On Beta version of 1.6 for NT w/ Svc Pack 6. I get following error. This used to work on both 1.5 and Alpha. This is need to keep track of Non Numeric values. >>> INF = 1e+110000 OverflowError: cannot convert float infinity to long For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470 From noreply@sourceforge.net Mon Aug 14 16:51:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 08:51:33 -0700 Subject: [Python-bugs-list] [Bug #110829] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <200008141551.IAA01172@delerium.i.sourceforge.net> Bug #110829, was updated on 2000-Aug-01 14:12 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: Feature Request Priority: 5 Summary: REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Details: Jitterbug-Id: 166 Submitted-By: aa8vb@ipass.net Date: Wed, 22 Dec 1999 07:57:58 -0500 (EST) Version: 1.5.2 OS: Irix In implementing a Python reader for VPF GIS data, I noticed that the struct module makes it very easy to read in data that may be in a different byte order than the local machine: val = struct.unpack( "" byte order prefixes used in the struct module were added to the array module. Thanks, Randall ==================================================================== Audit trail: Wed Jan 12 18:16:54 2000 guido changed notes Wed Jan 12 18:16:54 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:12 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 09:30:21 -0500 > In implementing a Python reader for VPF GIS data, I noticed that the struct > module makes it very easy to read in data that may be in a different byte > order than the local machine: > > val = struct.unpack( " > This parses from a little-endian file/buffer, and swaps bytes "if needed" to > the endianness of the local machine. > > However, using the array module is not so convenient. The developer has to > write code to sense the byte order of the local machine, and tell the > array module whether or not to swap bytes. I.e. there is no > "swap to native byte order" functionality: > > def _IsByteSwapNeeded( file_byte_order ): > """ The array module doesn't do byte swapping to the native byte order. > So we have to get under the hood and check it ourselves. > """ > def host_endian(): > if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' > else: return 'M' (I presume 'L' is little-endian, but what does 'M' stand for?) > assert file_byte_order in 'LM' > return ( host_endian() != file_byte_order ) > > a = array.array( "l", buf ) > if _IsByteSwapNeeded( 'L' ): > a.byteswap() > val = a.tolist() > > > The reason for using the array module (versus the struct module with > repeat counts) is for more efficient memory storage and access of large > numbers of lists containing large numbers of coordinates. struct insists > on converting everything at once, and the length must be exactly right. > array provides direct access to the any element of slice of a list so it > is my preferred choice. > > It would be useful if the "<" and ">" byte order prefixes used > in the struct module were added to the array module. You're right that this is more work than it should be. However I don't think that adding '<' to the format string is the right solution -- the format string declares the format of the data in the array, not how it should be converted from elsewhere. (The array module has other uses besides I/O of binary data.) I can see several solutions: - Add a byte order indicator to some standard module (e.g. the array module, or the sys module) so you can write a = array.array("l", buf) if sys.byte_order == 'big': a.byteswap() - Add a byte order flag to all the array methods that add raw data to the array object (constructor, fromfile(), fromstring(); and for symmetry also to the methods that write raw data out (tofile(), tostring()). A problem with tofile() is that in order to do the byteswap we'd either have to allocate temporary memory or byteswap in place, and then byteswap back after writing. I vote for the byte order indicator, giving total control to the user. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: "Fred L. Drake, Jr." Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 10:43:32 -0500 (EST) guido@cnri.reston.va.us writes: > I vote for the byte order indicator, giving total control to the user. I agree, but I'd also like to see an indicator for the native byte order somewhere (like sys) as well. (How possible would this be for JPython, Barry?) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 11:45:34 -0500 > guido@cnri.reston.va.us writes: > > I vote for the byte order indicator, giving total control to the user. > > I agree, but I'd also like to see an indicator for the native byte > order somewhere (like sys) as well. (How possible would this be for > JPython, Barry?) Ack! I was ambiguous! I meant to see a native byte order somewhere! --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: "Barry A. Warsaw" Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Wed, 22 Dec 1999 11:59:07 -0500 (EST) >>>>> "Fred" == writes: Fred> I agree, but I'd also like to see an indicator for the Fred> native byte order somewhere (like sys) as well. (How Fred> possible would this be for JPython, Barry?) Java's native format is bigendian, regardless of the system's underlying endian-ness. I'm not aware of any way of figuring out what the system's endian-ness is. -Barry ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: From: Randall Hopper Subject: Re: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Date: Thu, 30 Dec 1999 19:19:09 -0500 Guido van Rossum: |Randall Hopper: |> However, using the array module is not so convenient. The developer has to |> write code to sense the byte order of the local machine, and tell the |> array module whether or not to swap bytes. I.e. there is no |> "swap to native byte order" functionality: |> |> def _IsByteSwapNeeded( file_byte_order ): |> """ The array module doesn't do byte swapping to the native byte order. |> So we have to get under the hood and check it ourselves. |> """ |> def host_endian(): |> if ord( array.array( "i", [1] ).tostring()[ 0 ] ): return 'L' |> else: return 'M' | |(I presume 'L' is little-endian, but what does 'M' stand for?) L/M - LSB/MSB - [L]east/[M]ost Significant Byte First though: L/B - [L]ittle/[B]ig Endian might have been more intuitive. |However I don't think that adding '<' to the format string is the |right solution -- the format string declares the format of the data in |the array, not how it should be converted from elsewhere. (The array |module has other uses besides I/O of binary data.) ... |I can see several solutions: |- Add a byte order indicator to some standard module (e.g. the array | module, or the sys module) so you can write a = array.array("l", buf) if | sys.byte_order == 'big': a.byteswap() |- Add a byte order flag to all the array methods that add raw data to | the array object (constructor, fromfile(), fromstring(); and for | symmetry also to the methods that write raw data out (tofile(), | tostring()). A problem with tofile() is that in order to do the | byteswap we'd either have to allocate temporary memory or byteswap in | place, and then byteswap back after writing. Having considered this again from what you've said, I agree that a byte order indicator would probably be better for the array case. I see your point: temporary buffers for reads or writes would be needed since array is a type used for storage whereas struct is not. A byte order indicator leads to more user code in doing the byte swapping and is inconsistent with struct's, but it does avoid all (potentially large) temporary buffer generation whether byte swapping is needed or not, which is important. Thanks, Randall ------------------------------------------------------- Date: 2000-Aug-01 14:12 By: none Comment: Actually, all we need is a simpler way to discover the native byte order. A flag in the struct module would do just fine. ------------------------------------------------------- Date: 2000-Aug-14 08:51 By: fdrake Comment: The sys.byte_order indicator is now in CVS, and will be available in Python 2.0. I think there's nothing left to fix. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110829&group_id=5470 From noreply@sourceforge.net Mon Aug 14 17:23:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 09:23:10 -0700 Subject: [Python-bugs-list] [Bug #111858] Python-1.6b1 uses _cursesmodule.so Message-ID: <200008141623.JAA18949@bush.i.sourceforge.net> Bug #111858, was updated on 2000-Aug-14 05:08 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: Python-1.6b1 uses _cursesmodule.so Details: Compiling the curses module for Python-1.6b1 only after renaming cursesmodule.c to _cursesmodule.c in Modules/Setup. Moreover, this will result in building cursesmodule.so instead of _cursesmodule.so as expected by Lib/curses. Follow-Ups: Date: 2000-Aug-14 09:23 By: fdrake Comment: This has since been fixed in CVS. Make sure you are using a Setup or Setup.local that reflects the current state of Setup.in in this regard. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111858&group_id=5470 From noreply@sourceforge.net Tue Aug 15 01:23:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 17:23:02 -0700 Subject: [Python-bugs-list] [Bug #111866] Overflow Error Message-ID: <200008150023.RAA19747@delerium.i.sourceforge.net> Bug #111866, was updated on 2000-Aug-14 07:21 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Overflow Error Details: On Beta version of 1.6 for NT w/ Svc Pack 6. I get following error. This used to work on both 1.5 and Alpha. This is need to keep track of Non Numeric values. >>> INF = 1e+110000 OverflowError: cannot convert float infinity to long Follow-Ups: Date: 2000-Aug-14 17:23 By: tim_one Comment: Curious. It's an accident that it ever "worked" -- *any* visible behavior with infinities and NaNs is an accident in Python, as the language implementation knows nothing about them. I'll get this to work somehow. In the meantime, consider using INF = 1e300**2 instead. That still "works", although also by accident. If you later try hash(INF), it will blow up with the same msg you originally got (your error actually occurs at compile-time, while Python is using an invisible dict to keep track of the constants it's seen -- your 1e+110000 actually works fine (although *that's* an accident of the way Microsoft's input routines work!), and it's the internal hashing of the resulting double value that blows up). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470 From noreply@sourceforge.net Tue Aug 15 01:47:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 17:47:54 -0700 Subject: [Python-bugs-list] [Bug #110670] Win32 os.listdir raises confusing errors (PR#374) Message-ID: <200008150047.RAA20465@delerium.i.sourceforge.net> Bug #110670, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: Win32 os.listdir raises confusing errors (PR#374) Details: Jitterbug-Id: 374 Submitted-By: tpeters@beopen.com Date: Thu, 29 Jun 2000 02:25:18 -0400 (EDT) Version: 1.6a2 OS: Windows Copying this over from the SourceForge bug manager: https://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=108381 Here's the original complaint: On Win32, os.listdir raises "No such process" when the directory does not exist. The error returned from GetLastError really is ERROR_PATH_NOT_FOUND, not ESRCH. Here's confirmation under Win98 1.6a2: C:\Python16>python Python 1.6a2 (#0, Apr 6 2000, 11:45:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import os >>> os.listdir('/cow') Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 3] No such process: '/cow' >>> ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110670&group_id=5470 From noreply@sourceforge.net Tue Aug 15 02:40:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 18:40:19 -0700 Subject: [Python-bugs-list] [Bug #110642] freeze with "-s service" and "-m" (PR#315) Message-ID: <200008150140.SAA22130@delerium.i.sourceforge.net> Bug #110642, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Closed Resolution: Fixed Bug Group: Feature Request Priority: 5 Summary: freeze with "-s service" and "-m" (PR#315) Details: Jitterbug-Id: 315 Submitted-By: tdickenson@geminidataloggers.com Date: Fri, 5 May 2000 05:50:37 -0400 (EDT) Version: 1.5.2 OS: Windows There is a problem with combining two different options to freeze. Those options are: 1. "-s service" indicating that the frozen program is a windows service. one effect of this is that the myscript.py file on the freeze command line should be available for import, not as __main__ 2. "-m" indicating that extra modules are to be included in the freeze. The relevant block of code is at line 335... # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: if modargs: mf.import_hook(scriptfile) else: mf.load_file(scriptfile) For a service, the outer 'else' block is entered. If -m is not specified then the inner 'else' block is entered. mf.load_file assumes its parameter is a filename (to be imported from), an everything is happy. If -m is specified then the inner 'if' block is entered. mf.import_hook assumes its parameter is a module to imported. This fails because "myscript.py" is not a module name, and can not be imported. I think this block of code was naively copy/pasted from the block above it (where it correctly implements the -m option), and never tested with the -m option. This block (starting line 335) should be replaced with # Add the main script as either __main__, or the actual module name. if python_entry_is_main: mf.run_script(scriptfile) else: mf.load_file(scriptfile) I have tested this patch on windows, freezing service and non-service scripts, both with and without -m ==================================================================== Audit trail: Mon May 22 17:28:43 2000 guido changed notes Mon May 22 17:28:43 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:10 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] freeze with "-s service" and "-m" (PR#315) Date: Fri, 5 May 2000 23:19:14 +1000 > I think this block of code was naively copy/pasted from the > block above it Quite likely! > This block (starting line 335) should be replaced with ... If you submit a patch to this effect (to the patches address), I would be happy to bless it (and given that the service code is mine, I guess that would be all that is needed...) Thanks, Mark. ------------------------------------------------------- Date: 2000-Aug-14 18:40 By: mhammond Comment: Fixed in Rev. 1.35 of freeze.py ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110642&group_id=5470 From noreply@sourceforge.net Tue Aug 15 03:09:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 19:09:46 -0700 Subject: [Python-bugs-list] [Bug #111928] obsolete use of socket.connect() Message-ID: <200008150209.TAA07365@bush.i.sourceforge.net> Bug #111928, was updated on 2000-Aug-14 19:09 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Open Resolution: None Bug Group: None Priority: 5 Summary: obsolete use of socket.connect() Details: in 1.6b1 tree under "Demo/sockets", there are obsolete use of socket.connect() still present. Index: Demo/sockets/finger.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/finger.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 finger.py --- Demo/sockets/finger.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/finger.py 2000/08/15 02:08:12 @@ -23,7 +23,7 @@ # def finger(host, args): s = socket(AF_INET, SOCK_STREAM) - s.connect(host, FINGER_PORT) + s.connect((host, FINGER_PORT)) s.send(args + '\n') while 1: buf = s.recv(1024) Index: Demo/sockets/ftp.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/ftp.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 ftp.py --- Demo/sockets/ftp.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/ftp.py 2000/08/15 02:08:12 @@ -48,7 +48,7 @@ # Create control connection # s = socket(AF_INET, SOCK_STREAM) - s.connect(hostname, FTP_PORT) + s.connect((hostname, FTP_PORT)) f = s.makefile('r') # Reading the replies is easier from a file... # # Control loop @@ -79,7 +79,7 @@ port = nextport + FTP_DATA_PORT nextport = (nextport+1) % 16 r = socket(AF_INET, SOCK_STREAM) - r.bind(gethostbyname(gethostname()), port) + r.bind((gethostbyname(gethostname()), port)) r.listen(1) sendportcmd(s, f, port) return r Index: Demo/sockets/telnet.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/telnet.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 telnet.py --- Demo/sockets/telnet.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/telnet.py 2000/08/15 02:08:12 @@ -51,7 +51,7 @@ s = socket(AF_INET, SOCK_STREAM) # try: - s.connect(host, port) + s.connect((host, port)) except error, msg: sys.stderr.write('connect failed: ' + `msg` + '\n') sys.exit(1) Index: Demo/sockets/throughput.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/throughput.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 throughput.py --- Demo/sockets/throughput.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/throughput.py 2000/08/15 02:08:12 @@ -72,7 +72,7 @@ t1 = time.time() s = socket(AF_INET, SOCK_STREAM) t2 = time.time() - s.connect(host, port) + s.connect((host, port)) t3 = time.time() i = 0 while i < count: For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111928&group_id=5470 From noreply@sourceforge.net Tue Aug 15 04:35:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 14 Aug 2000 20:35:13 -0700 Subject: [Python-bugs-list] [Bug #111866] Overflow Error Message-ID: <200008150335.UAA10074@bush.i.sourceforge.net> Bug #111866, was updated on 2000-Aug-14 07:21 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: Overflow Error Details: On Beta version of 1.6 for NT w/ Svc Pack 6. I get following error. This used to work on both 1.5 and Alpha. This is need to keep track of Non Numeric values. >>> INF = 1e+110000 OverflowError: cannot convert float infinity to long Follow-Ups: Date: 2000-Aug-14 17:23 By: tim_one Comment: Curious. It's an accident that it ever "worked" -- *any* visible behavior with infinities and NaNs is an accident in Python, as the language implementation knows nothing about them. I'll get this to work somehow. In the meantime, consider using INF = 1e300**2 instead. That still "works", although also by accident. If you later try hash(INF), it will blow up with the same msg you originally got (your error actually occurs at compile-time, while Python is using an invisible dict to keep track of the constants it's seen -- your 1e+110000 actually works fine (although *that's* an accident of the way Microsoft's input routines work!), and it's the internal hashing of the resulting double value that blows up). ------------------------------------------------------- Date: 2000-Aug-14 20:35 By: tim_one Comment: Fixed in the CVS tree. I don't intend to backstitch this into 1.6, though, because it required a lot of code shuffling in new-in-2.0 code. The fix will be in the 2.0 release. Following is the checkin msg: Fix for http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470. This was a misleading bug -- the true "bug" was that hash(x) gave an error return when x is an infinity. Fixed that. Added new Py_IS_INFINITY macro to pyport.h. Rearranged code to reduce growing duplication in hashing of float and complex numbers, pushing Trent's earlier stab at that to a logical conclusion. Fixed exceedingly rare bug where hashing of floats could return -1 even if there wasn't an error (didn't waste time trying to construct a test case, it was simply obvious from the code that it *could* happen). Improved complex hash so that hash(complex(x, y)) doesn't systematically equal hash(complex(y, x)) anymore. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: python/dist/src/Include/pyport.h CVS: python/dist/src/Objects/complexobject.c CVS: python/dist/src/Objects/floatobject.c CVS: python/dist/src/Objects/longobject.c CVS: python/dist/src/Objects/object.c CVS: ---------------------------------------------------------------------- ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470 From elcultural.com@python.org Tue Aug 15 04:40:15 2000 From: elcultural.com@python.org (elcultural.com@python.org) Date: Mon, 14 Aug 2000 23:40:15 -0400 (EDT) Subject: [Python-bugs-list] Actualidad cultural en Internet (PR#431) Message-ID: <20000815034015.006281CFD1@dinsdale.python.org> Actualidad Cultural <body> <style type="text/css"> <!-- .sinsubrayado { font-family: Arial, Helvetica, sans-serif; font-size: 9pt; font-style: normal; font-weight: bold; text-decoration: none; text-align: centre; color: #000000} --> </style> <table cellspacing="0" cellpadding="0" border="0"> <tr> <td width="7" height="18" valign="top"></td> <td width="126" height="37" colspan="3" rowspan="2" valign="middle"><img SRC="http://www.elcultural.com/correo/img/elcultural.jpg" height=13 width=123></td> <td width="79" height="18" valign="top"></td> <td width="4" height="18" valign="top"></td> <td width="6" height="18" valign="top"></td> <td width="36" height="18" valign="top"></td> <td width="12" height="18" valign="top"></td> <td width="92" height="18" valign="top"></td> <td width="12" height="18" valign="top"></td> <td width="172" height="18" valign="top"></td> </tr> <tr> <td width="7" height="19" valign="top"></td> <td width="79" height="19" valign="top"></td> <td width="4" height="19" valign="top"></td> <td width="6" height="19" valign="top"></td> <td width="36" height="19" valign="top"></td> <td width="12" height="19" valign="top"></td> <td width="92" height="19" valign="top"></td> <td width="12" height="19" valign="top"></td> <td width="172" height="617" rowspan="16" valign="top" bgcolor="#FFFFCC"> <center><p><a href="http://www.elcultural.com"><img SRC="http://www.elcultural.com/correo/img/logo2.gif" BORDER=0 height=56 width=68></a></p> <p><b><font face="Arial,Helvetica"><font size=-2>Otros Titulares</font></font></b> </p> </center> <p align="left"><font size=-2><font face="Wingdings"> &nbsp;n<font face="Arial, Helvetica, sans-serif" size="1"> <a href="http://elcultural.com/contenidos/tema/270700/1.asp">Danza contempor&aacute;nea en Andaluc&iacute;a, la hermana pobre de las artes esc&eacute;nicas</a></font></font></font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n </font> </font> <font face="Arial,Helvetica"><font size=-1><a href="http://www.elcultural.com/contenidos/reportaje/230700/1.asp"><font size="1">De sur a sur, creadores africanos en Espa&ntilde;a</font></a></font></font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n </font><font size=-2><font face="Wingdings"><font face="Arial, Helvetica, sans-serif" size="1"><a href="http://www.elcultural.com/contenidos/denominacion/310700/1.asp">Chano Dom&iacute;nguez, jazzeando por Buler&iacute;as</a></font></font></font> </font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n </font></font><font size="1" face="Arial, Helvetica, sans-serif"><a href="http://elcultural.com/contenidos/entrevista/250700/1.asp">Eduardo Haro Tecglen, "Asisto con horror a la lucha de los poderes por Internet"</a></font> <p align="left"><font size="1" face="Arial, Helvetica, sans-serif"><br> </font> <p align="left"> <center> <center> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/">Portada</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com">Noticias culturales</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/dinamica/index.html">Versi&oacute;n multimedia</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/criticas/default.asp">Cr&iacute;tica de eventos</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/resenas/cds/default.asp">Rese&ntilde;as de discos</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/resenas/libros/default.asp">Rese&ntilde;as de libros</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com">Cartelera de Andaluc&iacute;a</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/eva/index.html">Espacio Virtual de las Artes</a></font></font> <br> <font size="1" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/contenidos/arquitec/20000720/default.asp">Ar quitectura </a></font><br> <font size="1" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/contenidos/webdelasemana/default.asp">Web de la Semana</a></font><br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/andalucia/default.asp">Andaluc&iacute;a Cultural</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/entrevista/default.asp">Entrevist as</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/reportaje/default.asp">Reportajes </a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/evento/default.asp">Eventos</a></ font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/denominacion/default.asp">Denomin aci&oacute;n de Origen</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/tema/default.asp">Temas de Actualidad</a></font></font> </center> </center></td> </tr> <tr> <td width="7" height="22" valign="top"></td> <td width="355" height="22" colspan="9" valign="top" bgcolor="#FFFFCC"><table width="100%" border="0" mm_noconvert="TRUE"> <tr> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/cine.asp"><font color="#000099"><b>cine</b></font></a></font></td> <td><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/temas/arte.asp"><b><font color="#000099">arte</font></b></a></font></td> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/escena.asp"><font color="#000099"><b>escena</b></font></a></font></td> <td><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/temas/musica.asp"><font color="#000099"><b>m&uacute;sica</b></font></a></font></td> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/literatura.asp"><b><font color="#000099">literatura</font></b></a></font></td> </tr> </table></td> <td width="12" height="22" valign="top"></td> </tr> <tr> <td width="7" height="8" valign="top"></td> <td width="104" height="8" valign="top"></td> <td width="7" height="8" valign="top"></td> <td width="15" height="8" valign="top"></td> <td width="79" height="8" valign="top"></td> <td width="4" height="8" valign="top"></td> <td width="6" height="8" valign="top"></td> <td width="36" height="8" valign="top"></td> <td width="12" height="8" valign="top"></td> <td width="92" height="8" valign="top"></td> <td width="12" height="8" valign="top"></td> </tr> <tr> <td width="7" height="136" valign="top"></td> <td width="355" height="136" colspan="9" valign="top"><b><font face="Arial, Helvetica, sans-serif" size="3">Juan Manuel de Prada: &quot;Concibo el paraíso bajo la especie de una biblioteca"</font><font face="Arial, Helvetica, sans-serif" size="4"><br> </font><font size="1" face="Arial, Helvetica, sans-serif"> <a href="http://elcultural.com/contenidos/entrevista/20000707/1.asp"><img src="http://www.elcultural.com/correo/img/prada.jpg" width="100" height="90" align="left" border="0"></a>Año y medio después de ganar el Planeta, Juan Manuel de Prada regresa al primer plano literario con una monumental novela biográfica sobre la escritora Ana María Martínez Sagi. Las esquinas del aire (Planeta) es un cruce de géneros que rescata del olvido a una figura fascinante que alternó la poesía con el lanzamiento de jabalina, y la militancia feminista con el periodismo. <a href="http://elcultural.com/contenidos/entrevista/20000707/1.asp">M&aacute;s Informaci&oacute;n</a></font></b></td> <td width="12" height="136" valign="top"></td> </tr> <tr> <td width="7" height="25" valign="top"></td> <td width="355" height="25" colspan="9" valign="top"> <hr WIDTH="350"></td> <td width="12" height="25" valign="top"></td> </tr> <tr> <td width="7" height="48" valign="top"></td> <td width="355" height="48" colspan="9" valign="top"> <p><font size="4" face="Arial, Helvetica, sans-serif">M&aacute;laga acoge una muestra del creador ecuatoriano Oswaldo Guayasam&iacute;n</font><font size="1" face="Arial, Helvetica, sans-serif"> </font></p> </td> <td width="12" height="48" valign="top"></td> </tr> <tr> <td width="7" height="105" valign="top"></td> <td width="251" height="105" colspan="7" valign="top"><font size="1" face="Arial, Helvetica, sans-serif">La exposición - que ya se presentó la pasada primavera en Córdoba y Sevilla -reúne 83 óleos y acrílicos que se complementa con una serie de paneles explicativos sobre su proyecto más ambicioso: La Capilla del hombre. Con una gran fuerza plástica y un enorme valor simbólico los cuadros de Guayasamín suo si hace falta, como en su disco "Imán".<br> <b><font size="1" face="Arial, Helvetica, sans-serif"><a href="http://elcultural.com/contenidos/evento/090800/1.asp">M&aacute;s Informaci&oacute;n</a></font></b> </font></td> <td width="12" height="105" valign="top"></td> <td width="92" height="105" valign="top"> <p align="center"><a href="http://elcultural.com/contenidos/evento/090800/1.asp"><img src="http://www.elcultural.com/correo/img/guayasamin.jpg" width="81" height="101" border="0"></a></p> </td> <td width="12" height="105" valign="top"></td> </tr> <tr> <td width="7" height="25" valign="top"></td> <td width="355" height="25" colspan="9" valign="top"> <hr WIDTH="100%"></td> <td width="12" height="25" valign="top"></td> </tr> <tr> <td width="7" height="4" valign="top"></td> <td width="104" height="4" valign="top"></td> <td width="7" height="4" valign="top"></td> <td width="15" height="4" valign="top"></td> <td width="79" height="4" valign="top"></td> <td width="4" height="4" valign="top"></td> <td width="6" height="4" valign="top"></td> <td width="140" height="109" colspan="3" rowspan="4" valign="top"> <table width="100%" border="0" cellspacing="1" cellpadding="01" mm_noconvert="TRUE"> <tr> <td> <div align="center"><span class="nombreseccion"><font face="Arial, Helvetica, sans-serif" size="2"><b>Eventos recomendados</b></font></span></div> </td> </tr> <tr> <td> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3613," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">Almer&iacute;a</font></a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3923," class="titular"><font face="Arial, Helvetica, sans-serif" size="2">C&aacute;diz</font></a></span></div> </td> </tr> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3971," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">C&oacute;rdoba</font></a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4078," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">Granada</font></a></span></div> </td> </tr> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4056," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">Huelva</font> </a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4074," class="titular"><font face="Arial, Helvetica, sans-serif" size="2">Ja&eacute;n</font></a></span></div> </td> </tr> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4090," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">M&aacute;laga</font></a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3681," class="titular"><font face="Arial, Helvetica, sans-serif" size="2">Sevilla</font></a></span></div> </td> </tr> </table> </td> </tr> </table></td> <td width="12" height="4" valign="top"></td> </tr> <tr> <td width="7" height="41" valign="top"></td> <td width="209" height="41" colspan="5" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Denominaci&oacute;n de Origen<br> <font size="1"><a href="http://elcultural.com/contenidos/denominacion/140800/1.asp">Enrique Santana (Pintor) </a></font></font></td> <td width="6" height="41" valign="top"></td> <td width="12" height="41" valign="top"></td> </tr> <tr> <td width="7" height="42" valign="top"></td> <td width="205" height="42" colspan="4" valign="top"><font face="Arial,Helvetica"><font size=-1>Reportaje<br> <font size="1"><a href="http://elcultural.com/contenidos/reportaje/070800/1.asp">Arte entre rejas, talentos en la c&aacute;rcel</a></font><br> </font></font></td> <td width="4" height="42" valign="top"></td> <td width="6" height="42" valign="top"></td> <td width="12" height="42" valign="top"></td> </tr> <tr> <td width="7" height="22" valign="top"></td> <td width="205" height="38" colspan="4" rowspan="2" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Entrevista<br> </font><font size="1" face="Arial, Helvetica, sans-serif"><a href="http://elcultural.com/bflamenco/entrevistas03.htm">Antonio El Pipa: &quot;Mi meta es morirme bailando&quot;</a></font> <font face="Arial, Helvetica, sans-serif" size="2"> </font></td> <td width="4" height="22" valign="top"></td> <td width="6" height="22" valign="top"></td> <td width="12" height="22" valign="top"></td> </tr> <tr> <td width="7" height="16" valign="top"></td> <td width="4" height="16" valign="top"></td> <td width="6" height="16" valign="top"></td> <td width="140" height="120" colspan="3" rowspan="4" valign="top"><a href="http://www.elcultural.com/bflamenco/index.htm"><b><font face="Arial, Helvetica, sans-serif" size="1" class="sinsubrayado"> <center> </center> </font></b></a> <div align="center"> <p><b><font size="1" face="Arial, Helvetica, sans-serif">En elcultural.com</font></b> </p> </div> <div align="center"><a href="http://www.elcultural.com/bflamenco"><img width="90" height="90" src="http://www.elcultural.com/correo/img/banner90.gif" border="0"></a></div> </td> <td width="12" height="16" valign="top"></td> </tr> <tr> <td width="7" height="35" valign="top"></td> <td width="205" height="35" colspan="4" valign="top"><font size="2" face="Arial, Helvetica, sans-serif">Web de la Semana</font><font size="1" face="Arial, Helvetica, sans-serif">: <br> <a href="http://elcultural.com/contenidos/webdelasemana/20000814.asp">Centro Andaluz de Flamenco</a></font></td> <td width="4" height="35" valign="top"></td> <td width="6" height="35" valign="top"></td> <td width="12" height="35" valign="top"></td> </tr> <tr> <td width="7" height="27" valign="top"></td> <td width="205" height="27" colspan="4" valign="top"> <hr> </td> <td width="4" height="27" valign="top"></td> <td width="6" height="27" valign="top"></td> <td width="12" height="27" valign="top"></td> </tr> <tr> <td width="7" height="42" valign="top"></td> <td width="104" height="50" rowspan="2" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Mirada adelante </font><br> <font size="2" face="Arial, Helvetica, sans-serif"><a href="http://elcultural.com/contenidos/madelante/140800/1.asp"><font size="1">&Aacute;ngel Sanzo, pianista</font></a></font></td> <td width="7" height="42" valign="top"></td> <td width="94" height="42" colspan="2" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Mirada atr&aacute;s<br> <a href="http://elcultural.com/contenidos/matras/040800/1.asp"><font size="1">Jos&eacute; Guerrero, pintor </font></a></font></td> <td width="4" height="42" valign="top"></td> <td width="6" height="42" valign="top"></td> <td width="12" height="42" valign="top"></td> </tr> <tr> <td width="7" height="8" valign="top"></td> <td width="7" height="8" valign="top"></td> <td width="15" height="8" valign="top"></td> <td width="79" height="8" valign="top"></td> <td width="4" height="8" valign="top"></td> <td width="6" height="8" valign="top"></td> <td width="36" height="8" valign="top"></td> <td width="12" height="8" valign="top"></td> <td width="92" height="8" valign="top"></td> <td width="12" height="8" valign="top"></td> <td width="172" height="8" valign="top"></td> </tr> <tr> <td width="7" height="53" valign="top"></td> <td width="539" height="53" colspan="11" valign="top"> <center> <p><font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/">portada </a>/ <a href="http://www.elcultural.com/dinamica/index.html">contenidos multimedias de la semana</a> / <a href="mailto:redaccion@elcultural.com">sugerencias</a> / <a href="http://www.elcultural.com/quienes/default.asp">sobre elcultural.com</a>/ <a href="http://www.elcultural.com/prensa/default.asp">dossier de prensa</a></font></font> <br> &nbsp;<br> <font face="Arial,Helvetica"><font size=-2>Si no quieres volver a recibir mensajes de elcultural.com pincha <a href="http://www.elcultural.com/suscripciones/baja.asp">aqu&iacute;</a> y b&oacute;rrate de la Secci&oacute;n Contenidos de Actualidad</font></font> </center></td> </tr> <tr> <td width="7" height="1" valign="top"><img width="7" height="1" src="transparent.gif"></td> <td width="104" height="1" valign="top"><img width="104" height="1" src="transparent.gif"></td> <td width="7" height="1" valign="top"><img width="7" height="1" src="transparent.gif"></td> <td width="15" height="1" valign="top"><img width="15" height="1" src="transparent.gif"></td> <td width="79" height="1" valign="top"><img width="79" height="1" src="transparent.gif"></td> <td width="4" height="1" valign="top"><img width="4" height="1" src="transparent.gif"></td> <td width="6" height="1" valign="top"><img width="6" height="1" src="transparent.gif"></td> <td width="36" height="1" valign="top"><img width="36" height="1" src="transparent.gif"></td> <td width="12" height="1" valign="top"><img width="12" height="1" src="transparent.gif"></td> <td width="92" height="1" valign="top"><img width="92" height="1" src="transparent.gif"></td> <td width="12" height="1" valign="top"><img width="12" height="1" src="transparent.gif"></td> <td width="172" height="1" valign="top"><img width="172" height="1" src="transparent.gif"></td> </tr> </table> </body> From noreply@sourceforge.net Tue Aug 15 15:31:07 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 07:31:07 -0700 Subject: [Python-bugs-list] [Bug #111961] urllib.quote and string.letters Message-ID: <200008151431.HAA14650@delerium.i.sourceforge.net> Bug #111961, was updated on 2000-Aug-15 07:31 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urllib.quote and string.letters Details: urllib.quote() uses string.letters for determining, if a character is save to be used in an url. In Python 1.5.2. this was only 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'. This seems to have changed in Python1.6b1 (or maybe it is the responsibility of the locale module) to 'abcdefghijklmnopqrstuvwxyz\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\ 370\371\372\373\374\375\376\377ABCDEFGHIJKLMNOPQRSTUVWXYZ\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\32 0\321\322\323\324\325\326\330\331\332\333\334\335\336' which changes the semantics of urllib.quote() For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111961&group_id=5470 From noreply@sourceforge.net Tue Aug 15 16:40:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 08:40:56 -0700 Subject: [Python-bugs-list] [Bug #111203] 1.6b1 build (docs?) pyexpat problem on Windows Message-ID: <200008151540.IAA01751@bush.i.sourceforge.net> Bug #111203, was updated on 2000-Aug-06 11:36 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: 1.6b1 build (docs?) pyexpat problem on Windows Details: pyexpat is not documented as one of those subprojects needing external software, but apparently it is one; it needs xmlparse and xmltok, .h and .lib to build and .dll to run. The docs don't mention where to get those from, but I had them around (from a Perl site build...) and feeding them to the Python 1.6b1 build fixed it. So I think it's just a doc-bug. Alex For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111203&group_id=5470 From noreply@sourceforge.net Tue Aug 15 16:51:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 08:51:28 -0700 Subject: [Python-bugs-list] [Bug #110628] Python 1.6a1 - Poor diagnostic (PR#278) Message-ID: <200008151551.IAA02155@bush.i.sourceforge.net> Bug #110628, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: None Bug Group: Feature Request Priority: 5 Summary: Python 1.6a1 - Poor diagnostic (PR#278) Details: Jitterbug-Id: 278 Submitted-By: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Date: 06 Apr 2000 11:10:00 -0400 Version: None OS: None Hello. This might be seen as a limitation, rather than a bug. This is not specific to 1.6a1, as 1.5.2 shows the same. Executing a Python script yields: Traceback (most recent call last): File "./to-html", line 26, in ? import data, htmlpage, localweb, registry SyntaxError: non-keyword arg after keyword arg (line 26) There is such an error in file `../lib/htmlpage.py' here, so the diagnostic is proper. However, a mere `(line 26)' does not hint about which of the four imported sources has the error. As a way around the poor diagnostic, you might suggest that I avoid bundling many imports on one line. This would help of course, but I still think Python could do better, here. -- François Pinard http://www.iro.umontreal.ca/~pinard ==================================================================== Audit trail: Mon May 22 17:50:15 2000 guido changed notes Mon May 22 17:50:15 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110628&group_id=5470 From noreply@sourceforge.net Tue Aug 15 16:53:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 15 Aug 2000 08:53:18 -0700 Subject: [Python-bugs-list] [Bug #110628] Python 1.6a1 - Poor diagnostic (PR#278) Message-ID: <200008151553.IAA02196@bush.i.sourceforge.net> Bug #110628, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: None Bug Group: Feature Request Priority: 5 Summary: Python 1.6a1 - Poor diagnostic (PR#278) Details: Jitterbug-Id: 278 Submitted-By: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Date: 06 Apr 2000 11:10:00 -0400 Version: None OS: None Hello. This might be seen as a limitation, rather than a bug. This is not specific to 1.6a1, as 1.5.2 shows the same. Executing a Python script yields: Traceback (most recent call last): File "./to-html", line 26, in ? import data, htmlpage, localweb, registry SyntaxError: non-keyword arg after keyword arg (line 26) There is such an error in file `../lib/htmlpage.py' here, so the diagnostic is proper. However, a mere `(line 26)' does not hint about which of the four imported sources has the error. As a way around the poor diagnostic, you might suggest that I avoid bundling many imports on one line. This would help of course, but I still think Python could do better, here. -- François Pinard http://www.iro.umontreal.ca/~pinard ==================================================================== Audit trail: Mon May 22 17:50:15 2000 guido changed notes Mon May 22 17:50:15 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-15 08:53 By: fdrake Comment: Changed SyntaxError generation and formatting to provide more information in the displayed message. The changes add the "filename" and "lineno" attributes to SyntaxError exceptions when those values are known. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110628&group_id=5470 From noreply@sourceforge.net Wed Aug 16 20:12:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 12:12:27 -0700 Subject: [Python-bugs-list] [Bug #112113] Built-in exception class not found: UnboundLocalError. Message-ID: <200008161912.MAA27225@bush.i.sourceforge.net> Bug #112113, was updated on 2000-Aug-16 12:12 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Built-in exception class not found: UnboundLocalError. Details: I've just compiled Python-1.6b1 for QNX4.25 and QNX/Neutrino 2.1. The Neutrino port works ... but the QNX 4.25 port make problems: # ./python Built-in exception class not found: UnboundLocalError. Library mismatch? Fatal Python error: Standard exceptions could not be initialized. %1 19800 Abort ./python # The lookdict() call returns a NULL value in the init phase of python. Any tips for fixing that problem? Regards Armin Steinhoff Armin@Steinhoff.de For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112113&group_id=5470 From noreply@sourceforge.net Wed Aug 16 23:18:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 15:18:43 -0700 Subject: [Python-bugs-list] [Bug #112123] bdist_wininst crashes with no long_description Message-ID: <200008162218.PAA01778@bush.i.sourceforge.net> Bug #112123, was updated on 2000-Aug-16 15:18 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Summary: bdist_wininst crashes with no long_description Details: The bdist_wininst command crashes if no long_description is specified: File "setup.py", line 48, in ? sources = [ File "/www/python/lib/python1.5/site-packages/distutils/core.py", line 112, in setup dist.run_commands () File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 776, in run_commands self.run_command (cmd) File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 797, in run_command cmd_obj.run () File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 115, in run self.create_exe (arcname, fullname) File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 171, in create_exe cfgdata = open (self.create_inifile()).read() File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 140, in create_inifile info = metadata.long_description + '\n' TypeError: bad operand type(s) for + For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112123&group_id=5470 From noreply@sourceforge.net Thu Aug 17 01:25:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 17:25:01 -0700 Subject: [Python-bugs-list] [Bug #110638] Invalid use of PyMem_DEL (PR#295) Message-ID: <200008170025.RAA06341@bush.i.sourceforge.net> Bug #110638, was updated on 2000-Jul-31 21:09 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 6 Summary: Invalid use of PyMem_DEL (PR#295) Details: Jitterbug-Id: 295 Submitted-By: niels@endea.demon.nl Date: Thu, 13 Apr 2000 14:16:25 -0400 (EDT) Version: 1.5.2 and 1.6.a2 OS: Win95 and Linux Hi, I ran into a bug while running a regrtest on 1.6a2 with debugging on. This produced a reference checking problem, which I now see is the same as reported in #113. I have tracked this down to the use of PyMem_DEL on an object created by PyObject_NEW in PyPcre_compile. When the compile fails, the new object is deallocated, but not removed from the reference chain. This also happens in 1.5.2. With a little grepping, I tracked down a few instances of this problem: pcremodule.c:PyPcre_compile unicodeobject.c:_PyUnicode_New socketmodule.c:newSSLObject threadmodule.c:newlockobject In each case a partially constructed, but already registered object is simply deleted without calling _Py_ForgetReference. ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-17 00:25 By: akuchling Comment: Fixed in revision 2.16 of Modules/pypcre.c . The other reported bugs also seem to be fixed in the CVS tree at this time. Thanks for your bug report! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110638&group_id=5470 From noreply@sourceforge.net Thu Aug 17 02:54:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 18:54:55 -0700 Subject: [Python-bugs-list] [Bug #110633] urlparse (PR#286) Message-ID: <200008170154.SAA09296@bush.i.sourceforge.net> Bug #110633, was updated on 2000-Jul-31 17:09 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urlparse (PR#286) Details: Jitterbug-Id: 286 Submitted-By: alex@shop.com Date: Mon, 10 Apr 2000 16:40:57 -0400 (EDT) Version: >=1.5 OS: win32 linux urlparse requires that the url contain a "/" so that urlparse("http://foo.com?q=a#blah") results in ("http","foo.com?q=a#blah",....) urlparse should not require slashes in urls that have fragments or query strings. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-16 21:54 By: fdrake Comment: Assigned to me so I can deal with urlparse all at once. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110633&group_id=5470 From noreply@sourceforge.net Thu Aug 17 03:02:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 16 Aug 2000 19:02:26 -0700 Subject: [Python-bugs-list] [Bug #110834] urlparse and HTTP parameters (PR#205) Message-ID: <200008170202.TAA09652@bush.i.sourceforge.net> Bug #110834, was updated on 2000-Aug-01 17:13 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: Later Bug Group: Feature Request Priority: 5 Summary: urlparse and HTTP parameters (PR#205) Details: Jitterbug-Id: 205 Submitted-By: mnot@akamai.com Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST) Version: 1.5.2 OS: All 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... ==================================================================== Audit trail: Wed Feb 23 21:39:30 2000 guido sent reply 1 Wed Feb 23 21:39:42 2000 guido changed notes Wed Feb 23 21:39:42 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 17:13 By: none Comment: From: Guido van Rossum Subject: Re: urlparse and HTTP parameters (PR#205) Date: Wed Feb 23 21:39:30 2000 Go for it! --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 17:13 By: none Comment: Go for it! ------------------------------------------------------- Date: 2000-Aug-16 22:02 By: fdrake Comment: An excellent idea; it can be incorporated in the existing urlparse module using new names. This won't be done for Python 2.0 at any rate, however. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110834&group_id=5470 From download@gratis1.com.ar Fri Aug 18 02:43:52 2000 From: download@gratis1.com.ar (download@gratis1.com.ar) Date: Thu, 17 Aug 2000 21:43:52 -0400 (EDT) Subject: [Python-bugs-list] help, can't install zope (PR#432) Message-ID: <20000818014352.E8DF11D08A@dinsdale.python.org> Full_Name: Manuel Alejandro Scalabroni Version: 1.52 OS: linux Submission from: a200042107169.rev.prima.com.ar (200.42.107.169) "This is due to the fact that certain libraries have been modified in a way that will not allow the compilation of python with threads support." This is the answer to why the tecnicians at cihost can't istall phyton for zope and mysql. Is it true? what version of phyton should they be installing with zope 2.2.0? the software i've asked is: MySQL_release____________________3.22.30 ZOPE_____________________________2.2.0 MySQLdb__________________________0.2.1 ZMySQLDA_________________________1.1.3 python_____________________________1.52 Apache Web server_______________________1.3.12 From download@gratis1.com.ar Fri Aug 18 02:44:02 2000 From: download@gratis1.com.ar (download@gratis1.com.ar) Date: Thu, 17 Aug 2000 21:44:02 -0400 (EDT) Subject: [Python-bugs-list] help, can't install zope (PR#433) Message-ID: <20000818014402.A62281D08A@dinsdale.python.org> Full_Name: Manuel Alejandro Scalabroni Version: 1.52 OS: linux Submission from: a200042107169.rev.prima.com.ar (200.42.107.169) "This is due to the fact that certain libraries have been modified in a way that will not allow the compilation of python with threads support." This is the answer to why the tecnicians at cihost can't istall phyton for zope and mysql. Is it true? what version of phyton should they be installing with zope 2.2.0? the software i've asked is: MySQL_release____________________3.22.30 ZOPE_____________________________2.2.0 MySQLdb__________________________0.2.1 ZMySQLDA_________________________1.1.3 python_____________________________1.52 Apache Web server_______________________1.3.12 From elcultural.com@python.org Fri Aug 18 05:52:54 2000 From: elcultural.com@python.org (elcultural.com@python.org) Date: Fri, 18 Aug 2000 00:52:54 -0400 (EDT) Subject: [Python-bugs-list] Cartelera de cine (PR#434) Message-ID: <20000818045254.89B711D296@dinsdale.python.org> Actualidad Cultural <body> <table cellspacing="0" cellpadding="0" border="0"> <tr> <td width="11" height="42" valign="top"></td> <td width="123" height="42" valign="middle"><img SRC="http://www.elcultural.com/correo/img/elcultural.jpg" height=13 width=123></td> <td width="9" height="42" valign="top"></td> <td width="8" height="42" valign="top"></td> <td width="70" height="42" valign="top"></td> <td width="5" height="42" valign="top"></td> <td width="24" height="42" valign="top"></td> <td width="39" height="42" valign="top"></td> <td width="7" height="42" valign="top"></td> <td width="73" height="42" valign="top"></td> <td width="9" height="42" valign="top"></td> <td width="173" height="42" valign="top"></td> </tr> <tr> <td width="11" height="22" valign="top"></td> <td width="358" height="22" colspan="9" valign="top" bgcolor="#FFFFCC"><table width="100%" border="0" mm_noconvert="TRUE"> <tr> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/cine.asp"><font color="#000099"><b>cine</b></font></a></font></td> <td><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/temas/arte.asp"><b><font color="#000099">arte</font></b></a></font></td> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/escena.asp"><font color="#000099"><b>escena</b></font></a></font></td> <td><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://www.elcultural.com/temas/musica.asp"><font color="#000099"><b>m&uacute;sica</b></font></a></font></td> <td><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/temas/literatura.asp"><b><font color="#000099">literatura</font></b></a></font></td> </tr> </table></td> <td width="9" height="22" valign="top"></td> <td width="173" height="590" rowspan="17" valign="top" bgcolor="#FFFFCC"> <center><p><a href="http://www.elcultural.com"><img src="http://www.elcultural.com/correo/img/logo2.gif" border=0 height=56 width=68></a></p> <p><b><font face="Arial,Helvetica"><font size=-2> Titulares</font></font></b> </p> </center> <p align="left"><font size=-2><font face="Wingdings"> &nbsp;n </font><font size="1" face="Arial, Helvetica, sans-serif"><a href="http://elcultural.com/bflamenco/entrevistas03.htm">Antonio El Pipa: &quot;Mi meta es morirme bailando&quot;</a></font> <font face="Arial, Helvetica, sans-serif" size="2"> </font></font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n</font></font><font face="Wingdings"><span class="titular"><a href="contenidos/denominacion/240700/1.asp" class="titular"><font face="Arial, Helvetica, sans-serif" size="1"> </font></a></span></font><font size=-2><font face="Wingdings"><font face="Arial, Helvetica, sans-serif" size="1"><a href="http://elcultural.com/contenidos/tema/270700/1.asp">Danza contempor&aacute;nea en Andaluc&iacute;a, la hermana pobre de las artes esc&eacute;nicas</a></font></font></font> <p align="left"><font size=-2><font size=-2><font face="Wingdings">&nbsp;n </font><font size="2" face="Arial, Helvetica, sans-serif"><a href="http://elcultural.com/contenidos/madelante/140800/1.asp"><font size="1">&Aacute;ngel Sanzo, pianista</font></a></font></font></font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n </font><font size=-2><font size=-2></font></font></font> <font face="Arial, Helvetica, sans-serif" size="1"><a href="http://www.elcultural.com/contenidos/reportaje/230700/1.asp">Una mirada a las propuestas de creadores africanos vinculados a España</a></font> <p align="left"><font size=-2><font face="Wingdings">&nbsp;n <span class="titular"><font face="Arial, Helvetica, sans-serif" size="1"><a href="http://www.elcultural.com/contenidos/reportaje/090700/1.asp" class="titular">Cine bajo las estrellas. Del patio de vecinos al patio de butaca.</a></font></span></font> </font> <center> <p> <p> <p> <hr WIDTH="70"> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/">Portada</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com">Noticias culturales</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/dinamica/index.html">Versi&oacute;n multimedia</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/criticas/default.asp">Cr&iacute;tica de eventos</a></font></font> <br> <a href="contenidos/arquitec/20000720/default.asp"><font face="Arial, Helvetica, sans-serif" size="1">Arquitectura </font></a><br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/resenas/cds/default.asp">Rese&ntilde;as de discos</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/resenas/libros/default.asp">Rese&ntilde;as de libros</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com">Cartelera de Andaluc&iacute;a</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/eva/index.html">Espacio Virtual de las Artes</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/andalucia/default.asp">Andaluc&iacute;a Cultural</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/entrevista/default.asp">Entrevist as</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/reportaje/default.asp">Reportajes </a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/evento/default.asp">Eventos</a></ font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/denominacion/default.asp">Denomin aci&oacute;n de Origen</a></font></font> <br> <font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/contenidos/tema/default.asp">Temas de Actualidad</a></font></font> </center> </td> </tr> <tr> <td width="11" height="4" valign="top"></td> <td width="123" height="4" valign="top"></td> <td width="9" height="4" valign="top"></td> <td width="8" height="4" valign="top"></td> <td width="70" height="4" valign="top"></td> <td width="5" height="4" valign="top"></td> <td width="24" height="4" valign="top"></td> <td width="39" height="4" valign="top"></td> <td width="7" height="4" valign="top"></td> <td width="73" height="4" valign="top"></td> <td width="9" height="4" valign="top"></td> </tr> <tr> <td width="11" height="23" valign="top"></td> <td width="358" height="23" colspan="9" valign="top" bgcolor="#CCCC99"><div align="center"><font face="Arial Black" size="3">CARTELERA DE CINE EN ANDALUC&Iacute;A</font></div></td> <td width="9" height="23" valign="top"></td> </tr> <tr> <td width="11" height="4" valign="top"></td> <td width="123" height="4" valign="top"></td> <td width="9" height="4" valign="top"></td> <td width="8" height="4" valign="top"></td> <td width="70" height="4" valign="top"></td> <td width="5" height="4" valign="top"></td> <td width="24" height="4" valign="top"></td> <td width="39" height="4" valign="top"></td> <td width="7" height="4" valign="top"></td> <td width="73" height="4" valign="top"></td> <td width="9" height="4" valign="top"></td> </tr> <tr> <td width="11" height="20" valign="top"></td> <td width="123" height="20" valign="top"></td> <td width="9" height="20" valign="top"></td> <td width="8" height="20" valign="top"></td> <td width="70" height="20" valign="top"></td> <td width="5" height="20" valign="top"></td> <td width="24" height="20" valign="top"></td> <td width="119" height="20" colspan="3" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">RECOMENDAMOS:</font></td> <td width="9" height="20" valign="top"></td> </tr> <tr> <td width="11" height="15" valign="top"></td> <td width="123" height="15" valign="top"></td> <td width="9" height="15" valign="top"></td> <td width="8" height="15" valign="top"></td> <td width="218" height="21" colspan="6" rowspan="2" valign="top"><div align="center"><font size="3" face="Arial, Helvetica, sans-serif"><b>Evasi&oacute;n en la granja</b></font></div></td> <td width="9" height="15" valign="top"></td> </tr> <tr> <td width="11" height="6" valign="top"></td> <td width="123" height="250" rowspan="4" valign="top"> <table width="124" border="0" cellspacing="0" cellpadding="0" height="239" mm_noconvert="TRUE"> <tr> <td> <div align="center"><img src="http://www.elcultural.com/correo/img/carteleracabbl.jpg" width="124" height="29"></div> </td> </tr> <tr> <td height="210"> <div align="center"> <table width="125" border="0" cellspacing="2" cellpadding="2"> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=8&amp;Poblaci on=1">Sevilla</a> </font></div> </td> </tr> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=3&amp;Poblaci on=1">C&oacute;rdoba</a> </font></div> </td> </tr> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=4&amp;Poblaci on=1">Granada</a> </font></div> </td> </tr> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=7&amp;Poblaci on=1">M&aacute;laga</a> </font></div> </td> </tr> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=6&amp;Poblaci on=1">Ja&eacute;n</a> </font></div> </td> </tr> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=1&amp;Poblaci on=1">Almer&iacute;a</a> </font></div> </td> </tr> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=5&amp;Poblaci on=1">Huelva</a> </font></div> </td> </tr> <tr> <td> <div align="center"><font face="Arial, Helvetica, sans-serif" size="2"><a href="http://www.elcultural.com/cartelera/cartelera.asp?Ciudad=2&amp;Poblaci on=1">C&aacute;diz</a> </font></div> </td> </tr> </table> <img src="http://www.elcultural.com/correo/img/cartelerainvbl.jpg" width="124" height="29"></div> </td> </tr> </table></td> <td width="9" height="6" valign="top"></td> <td width="8" height="6" valign="top"></td> <td width="9" height="6" valign="top"></td> </tr> <tr> <td width="11" height="13" valign="top"></td> <td width="9" height="13" valign="top"></td> <td width="8" height="13" valign="top"></td> <td width="138" height="90" colspan="4" rowspan="2" valign="top"><img src="http://www.elcultural.com/correo/img/chickenrun.jpg" width="131" height="86"></td> <td width="7" height="13" valign="top"></td> <td width="73" height="13" valign="top"></td> <td width="9" height="13" valign="top"></td> </tr> <tr> <td width="11" height="77" valign="top"></td> <td width="9" height="77" valign="top"></td> <td width="8" height="77" valign="top"></td> <td width="7" height="77" valign="top"></td> <td width="73" height="77" valign="top"> <p align="center"><font face="Arial, Helvetica, sans-serif" size="1">Chicken Run<br> (2000)</font> <br> <font size="1" face="Arial, Helvetica, sans-serif">Direcci&oacute;n: Peter Lord, Nick Park</font></p> </td> <td width="9" height="77" valign="top"></td> </tr> <tr> <td width="11" height="154" valign="top"></td> <td width="9" height="154" valign="top"></td> <td width="226" height="154" colspan="7" valign="top"><font face="Arial, Helvetica, sans-serif" size="1">Una de las películas más esperadas del verano, <i>Evasión en la granja</i> es el primer largometraje de los estudios británicos Aardman, pioneros de la artesanal animación en plastilina y ganadores de varios Oscars. Sin embargo, más allá de la técnica de animación por <i>slow motion</i> (fotograma a fotograma), que aporta un atractivo visual inusitado al filme, <i>Evasión en la granja</i> es un producto con suficientes atractivos para niños y adultos. Si los primeros disfrutarán las aventuras de las gallinas en su desesperada fuga de la granja, para los adultos se incluyen numerosas referencias genéricas.</font></td> <td width="9" height="154" valign="top"></td> </tr> <tr> <td width="11" height="27" valign="top"></td> <td width="358" height="27" colspan="9" valign="top"> <hr WIDTH="100%"></td> <td width="9" height="27" valign="top"></td> </tr> <tr> <td width="11" height="33" valign="top"></td> <td width="210" height="33" colspan="4" valign="top"><font face="Arial,Helvetica"><font size="2" face="Arial, Helvetica, sans-serif">Actualidad<br> <font size="1"><a href="http://elcultural.com/contenidos/evento/160800/1.asp">Zorrock 2000: pop, rock y hip hop en el coraz&oacute;n de Extremadura </a></font></font></font></td> <td width="5" height="33" valign="top"></td> <td width="143" height="225" colspan="4" rowspan="6" valign="top"> <table cellspacing="0" cellpadding="0" border="0" mm_noconvert="TRUE"> <tr> <td width="140" height="109" colspan="3" rowspan="4" valign="top"> <table width="100%" border="0" cellspacing="1" cellpadding="01" mm_noconvert="TRUE"> <tr> <td> <div align="center"><span class="nombreseccion"><font face="Arial, Helvetica, sans-serif" size="2"><b>Eventos recomendados</b></font></span></div> </td> </tr> <tr> <td> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3613," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">Almer&iacute;a</font></a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3923," class="titular"><font face="Arial, Helvetica, sans-serif" size="2">C&aacute;diz</font></a></span></div> </td> </tr> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3971," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">C&oacute;rdoba</font></a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4078," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">Granada</font></a></span></div> </td> </tr> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4056," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">Huelva</font> </a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4074," class="titular"><font face="Arial, Helvetica, sans-serif" size="2">Ja&eacute;n</font></a></span></div> </td> </tr> <tr> <td width="45%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,4090," class="titular"><font size="2" face="Arial, Helvetica, sans-serif">M&aacute;laga</font></a></span></div> </td> <td width="55%"> <div align="center"><span class="titular"><a href="http://www.elcultural.com/buscador/resultados.asp?Mf4G22S=,3681," class="titular"><font face="Arial, Helvetica, sans-serif" size="2">Sevilla</font></a></span></div> </td> </tr> </table> </td> </tr> </table> </td> </tr> <tr> </tr> <tr> </tr> <tr> </tr> <tr> <td width="140" height="120" colspan="3" rowspan="4" valign="top"><a href="http://www.elcultural.com/bflamenco/index.htm"><b><font face="Arial, Helvetica, sans-serif" size="1" class="sinsubrayado"> <center> </center> </font></b></a> <div align="center"> <p><b><font size="1" face="Arial, Helvetica, sans-serif">En elcultural.com</font></b> </p> </div> <div align="center"><a href="http://www.elcultural.com/bflamenco"><img width="90" height="90" src="http://www.elcultural.com/correo/img/banner90.gif" border="0"></a></div> </td> </tr> <tr> </tr> <tr> </tr> <tr> </tr> </table> </td> <td width="9" height="33" valign="top"></td> </tr> <tr> <td width="11" height="44" valign="top"></td> <td width="210" height="44" colspan="4" valign="top"><font face="Arial,Helvetica"><font size=-1>Entrevista<br> </font><font size="1"><a href="http://elcultural.com/contenidos/entrevista/20000707/1.asp">Juan Manuel de Prada: &quot;Concibo el para&iacute;so bajo la especie de una biblioteca&quot;</a></font></font></td> <td width="5" height="44" valign="top"></td> <td width="9" height="44" valign="top"></td> </tr> <tr> <td width="11" height="47" valign="top"></td> <td width="210" height="47" colspan="4" valign="top"><font face="Arial,Helvetica"><font size="2" face="Arial, Helvetica, sans-serif">Evento</font></font><br> <a href="http://elcultural.com/contenidos/evento/090800/1.asp"><font size="1" face="Arial, Helvetica, sans-serif">M&aacute;laga acoge una muestra del creador ecuatoriano Oswaldo Guayasam&iacute;n</font></a></td> <td width="5" height="47" valign="top"></td> <td width="9" height="47" valign="top"></td> </tr> <tr> <td width="11" height="33" valign="top"></td> <td width="210" height="33" colspan="4" valign="top"><font face="Arial,Helvetica"><font size="2" face="Arial, Helvetica, sans-serif">Web de la semana</font></font> <font face="Arial, Helvetica, sans-serif" size="2"><br> </font><font size="1" face="Arial, Helvetica, sans-serif"><a href="http://elcultural.com/contenidos/webdelasemana/20000814.asp">Centro Andaluz de Flamenco</a></font><font face="Arial, Helvetica, sans-serif" size="2"> </font></td> <td width="5" height="33" valign="top"></td> <td width="9" height="33" valign="top"></td> </tr> <tr> <td width="11" height="33" valign="top"></td> <td width="210" height="33" colspan="4" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Denominaci&oacute;n de Origen<br> </font><font face="Arial, Helvetica, sans-serif" size="2"><font size="1"><a href="http://elcultural.com/contenidos/denominacion/140800/1.asp">Enrique Santana (Pintor) </a></font></font></td> <td width="5" height="33" valign="top"></td> <td width="9" height="33" valign="top"></td> </tr> <tr> <td width="11" height="32" valign="top"></td> <td width="210" height="32" colspan="4" valign="top"><font face="Arial, Helvetica, sans-serif" size="2">Reportaje<br> </font><font face="Arial,Helvetica"><font size=-1><font size="1"><a href="http://elcultural.com/contenidos/reportaje/070800/1.asp">Arte entre rejas, talentos en la c&aacute;rcel</a></font></font></font><font face="Arial, Helvetica, sans-serif" size="2"> </font></td> <td width="5" height="32" valign="top"></td> <td width="9" height="32" valign="top"></td> </tr> <tr> <td width="11" height="6" valign="top"></td> <td width="123" height="6" valign="top"></td> <td width="9" height="6" valign="top"></td> <td width="8" height="6" valign="top"></td> <td width="70" height="6" valign="top"></td> <td width="5" height="6" valign="top"></td> <td width="24" height="6" valign="top"></td> <td width="39" height="6" valign="top"></td> <td width="7" height="6" valign="top"></td> <td width="73" height="6" valign="top"></td> <td width="9" height="6" valign="top"></td> <td width="173" height="6" valign="top"></td> </tr> <tr> <td width="11" height="74" valign="top"></td> <td width="540" height="74" colspan="11" valign="top"> <center> <p><font face="Arial,Helvetica"><font size=-2><a href="http://www.elcultural.com/">portada </a>/ <a href="http://www.elcultural.com/dinamica/index.html">contenidos multimedias de la semana</a> / <a href="mailto:redaccion@elcultural.com">sugerencias</a> / <a href="http://www.elcultural.com/quienes/default.asp">sobre elcultural.com</a>/ <a href="http://www.elcultural.com/prensa/default.asp">dossier de prensa</a></font></font> <br> &nbsp;<br> <font face="Arial,Helvetica"><font size=-2>Si no quieres volver a recibir mensajes de elcultural.com pincha <a href="http://www.elcultural.com/suscripciones/baja.asp">aqu&iacute;</a> y b&oacute;rrate de la Secci&oacute;n Contenidos de Actualidad</font></font> </center></td> </tr> <tr> <td width="11" height="1" valign="top"><img width="11" height="1" src="transparent.gif"></td> <td width="123" height="1" valign="top"><img width="123" height="1" src="transparent.gif"></td> <td width="9" height="1" valign="top"><img width="9" height="1" src="transparent.gif"></td> <td width="8" height="1" valign="top"><img width="8" height="1" src="transparent.gif"></td> <td width="70" height="1" valign="top"><img width="70" height="1" src="transparent.gif"></td> <td width="5" height="1" valign="top"><img width="5" height="1" src="transparent.gif"></td> <td width="24" height="1" valign="top"><img width="24" height="1" src="transparent.gif"></td> <td width="39" height="1" valign="top"><img width="39" height="1" src="transparent.gif"></td> <td width="7" height="1" valign="top"><img width="7" height="1" src="transparent.gif"></td> <td width="73" height="1" valign="top"><img width="73" height="1" src="transparent.gif"></td> <td width="9" height="1" valign="top"><img width="9" height="1" src="transparent.gif"></td> <td width="173" height="1" valign="top"><img width="173" height="1" src="transparent.gif"></td> </tr> </table> </body> From noreply@sourceforge.net Fri Aug 18 14:54:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 06:54:40 -0700 Subject: [Python-bugs-list] [Bug #112244] time.strptime() not present in Python 1.5.2 for MSWin Message-ID: <200008181354.GAA16818@bush.i.sourceforge.net> Bug #112244, was updated on 2000-Aug-18 13:54 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: time.strptime() not present in Python 1.5.2 for MSWin Details: Using Python 1.5.2 for MSWin, any attempt to use the time.strptime() function from the time module results in the error: AttributeError: strptime This error does not occur for the Unix version of Python 1.5.2. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112244&group_id=5470 From noreply@sourceforge.net Fri Aug 18 18:38:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 10:38:48 -0700 Subject: [Python-bugs-list] [Bug #112244] time.strptime() not present in Python 1.5.2 for MSWin Message-ID: <200008181738.KAA12162@delerium.i.sourceforge.net> Bug #112244, was updated on 2000-Aug-18 09:54 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: time.strptime() not present in Python 1.5.2 for MSWin Details: Using Python 1.5.2 for MSWin, any attempt to use the time.strptime() function from the time module results in the error: AttributeError: strptime This error does not occur for the Unix version of Python 1.5.2. Follow-Ups: Date: 2000-Aug-18 13:38 By: tim_one Comment: Changed to group Feature Request. strptime is available from Python only on those platforms where this (non-standard) C function happens to be available from the platform C library. Windows is not one of those. Not all Unix versions have it either. The docs already say that. The only way it will become available is if someone contributes an implementation. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112244&group_id=5470 From noreply@sourceforge.net Fri Aug 18 21:37:27 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 13:37:27 -0700 Subject: [Python-bugs-list] [Bug #112265] Impossible to get Win32 default font encoding in widgets Message-ID: <200008182037.NAA18712@delerium.i.sourceforge.net> Bug #112265, was updated on 2000-Aug-18 13:37 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Impossible to get Win32 default font encoding in widgets Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly. As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470 From noreply@sourceforge.net Fri Aug 18 21:37:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 13:37:26 -0700 Subject: [Python-bugs-list] [Bug #110664] PRIVATE: Bug in re module (PR#36) Message-ID: <200008182037.NAA18708@delerium.i.sourceforge.net> Bug #110664, was updated on 2000-Jul-31 21:11 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Wont Fix Bug Group: None Priority: 5 Summary: PRIVATE: Bug in re module (PR#36) Details: Jitterbug-Id: 36 Submitted-By: chenna@embl-heidelberg.de Date: Fri, 23 Jul 1999 06:51:43 -0400 (EDT) Version: 1.5.1 OS: OSF1 Hello I get Stack overflow: pid 14731, proc emparse1.py, addr 0x11fdfffd8, pc 0x120068cd8 Segmentation fault when I run the following. The problem is re module unable to search for the pattern that is too large, but this is a requirement for my application in biology. I enclose the source code with this. Please email me the solution as soon as possible Thanks Ramu ___________________________ #!/usr/pub/bin/python1.5 # # # # (C) Chenna Ramu, EMBL, Heidelberg, Germany # # parser for biological databases # import string import sys import re parserDict = { 'id' : r'((^ID [^\n]+\n)+)' , 'ac' : r'((^AC [^\n]+\n)+)' , 'dt' : r'((^DT [^\n]+\n)+)' , 'de' : r'((^DE [^\n]+\n)+)' , 'gn' : r'((^GN [^\n]+\n)+)' , 'os' : r'((^OS [^\n]+\n)+)' , 'oc' : r'((^OC [^\n]+\n)+)' , 'ref' : r'((' r'(^RN [^\n]+\n)' r'((^RP [^\n]+\n)+)' r'((^RX [^\n]+\n)?)' r'((^RA [^\n]+\n)+)' r'((^RT [^\n]+\n)*)' r'((^RL [^\n]+\n)+)' r')+)', 'cc' : r'((^CC [^\n]+\n)+)' , 'dr' : r'((^DR [^\n]+\n)+)' , 'kw' : r'((^KW [^\n]+\n)+)' , 'ft' : r'((^FT [^\n]+\n)+)' , 'sq' : r'(^SQ [^\n]+\n)' \ r'((^ [^\n]+\n)+)' } _hrefLink = {'embl':['%s','^DR ([^;]+)']} #should be like this hrefLink = {'EMBL':"%s", 'MIM':"%s"} em_rep = r'(^DR )(?P[^;]+); (?P[^;]+)' class embl: def __init__(self,parserDict={}): self.parserDict = {} self.reDict = {} #keep the compiled re's self.fields = [] if parserDict: self.Init(parserDict) def Init(self,parserDict): self.parserDict = parserDict self.fields = parserDict.keys() for j in self.fields: setattr(self, j, None) self.reDict[j] = re.compile(parserDict[j],re.MULTILINE) def Parse(self,str): if not self.parserDict: print "No parser specified" return for k,v in parserDict.items(): ## tmp = re.compile(v,re.MULTILINE) # move this to __init__ tmp = self.reDict[k] mat = tmp.search(str) if mat: setattr(self, k, mat.group() ) def Field(self,name): try: return getattr(self,name) except AttributeError: return None def PrintFields(self): flds = self.fields for j in flds: print "==> ",j print getattr(self,j) def ReParse(self,str,retToken,pat): """ str:string to parse, retToken:return token, pat:parser """ _p = re.compile(pat) m = _p.search(str) if m: return m.group(retToken) else: return None def Href(match): """ Replaces the hrefs """ dbase = match.group('dbase') id = match.group('id') try: defi = hrefLink[dbase] except KeyError: defi = None if defi: tmp = match.group(1) + dbase + '; '+defi %(dbase,id,id) else: tmp = match.group(1)+ dbase + '; ' + id return tmp def test(fileName): sys.path.insert(0,'/home/chenna/py') ## from seqFormat import * e = embl(parserDict) # f = open('acha_mouse.dat','r') f = open(fileName,'r') a = f.readlines() f.close() a = string.join(a,'') e.Parse(a) e.PrintFields() import string print ' the fields are ',e.fields ## seq = string.split(e.sq,';')[-1] ## s = Seq(seq,'test') ## print 'check===>',s.seq ## s.SeqPrint('swiss') seqLen = e.ReParse(e.sq[0:50],'seqLen',r'^SQ [^ ]+ *(?P(\d+))') print e.sq print "length of the sequence ",seqLen print e.ref dr = e.dr print dr p = re.compile(em_rep,re.M) dr = p.sub(Href,dr) print dr print e.Field('id') print e.Field('dr') print e.Field('mm') return def test1(dumm=None): tmp = ['SQ Sequence 1041931 BP; 8972 A; 5950 C; 6264 G; 8224 T; 0 other;\n'] for j in range(1,17365): t = ' ' + 'tcagtcagtg ' * 6 + '\n' tmp.append(t) a = string.join(tmp) e = embl(parserDict) e.Parse(a) e.PrintFields() if __name__ == '__main__': try: test1(sys.argv[1]) except: test1() ==================================================================== Audit trail: Sat Jul 24 16:53:53 1999 guido changed notes Sat Jul 24 16:53:53 1999 guido moved from incoming to open Sat Jul 24 17:04:17 1999 guido changed notes Follow-Ups: Date: 2000-Aug-06 20:53 By: twouters Comment: Fair chance this is already fixed, either in 1.5.2 remodule, or in the new 'sre' by Fredrik. Maybe /F can say something useful here. ------------------------------------------------------- Date: 2000-Aug-07 12:07 By: effbot Comment: It works fine under SRE, but bombs under PRE using a recent 2.0 build (tested on Windows). ------------------------------------------------------- Date: 2000-Aug-18 20:37 By: akuchling Comment: Boiled down test case: import string import pre as re pat = re.compile('(^ [^\n]+\n)+', re.MULTILINE) str = 17365 * ( ' ' + 'tcagtcagtg ' * 6 + '\n' ) pat.search( str ) The problem stems from nesting [^\n]+ inside a group that is then repeated. PCRE does a C recursion after matching [^\n]+, so on a long string the engine ends up nesting very deeply and filling the stack. With my knowledge of the engine, I see no way to rewrite the pattern to avoid this, so the program would have to be restructured to do its work differently. Not easily fixable without tearing PCRE apart; since SRE seems to survive this pattern, let's just count our blessings. :) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110664&group_id=5470 From noreply@sourceforge.net Sat Aug 19 03:48:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 19:48:46 -0700 Subject: [Python-bugs-list] [Bug #112288] os.path.commonprefix behaviour change. Message-ID: <200008190248.TAA31234@delerium.i.sourceforge.net> Bug #112288, was updated on 2000-Aug-19 12:48 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: os.path.commonprefix behaviour change. Details: From python-dev: On 1.5.2, the behaviour was: >>> os.path.commonprefix(["../foo/bar", "../foo/spam"]) '../foo/' While since the change we have: '../foo' Note that the trailing slash has been dropped. [snip existing code that was broken by this change - much debate on python-dev ensues about which is the more desirable behaviour.] Tim adds: I agree this is Bad Damage, and should be fixed before 2.0b1 goes out. Can you enter a bug report? [more debate about what is the better behaviour, and that the old way was obviously broken] Tim again: commonprefix worked exactly as documented for at least 6 years and 5 months (which is when CVS shows Guido checking in ntpath.py with the character-based functionality), and got out of synch with the docs about 5 weeks ago when Skip changed to this other algorithm. Since the docs *did* match the code, there's no reason to believe the original author was confused, and no reason to believe users aren't relying on it (they've had over 6 years to gripe ). And Tim yet again: When the code and the docs have matched for more than 6 years, there is no bug by any rational definition of the term, and you can be certain that changing the library semantics then will break existing code. Presuming to change it anyway is developer arrogance of the worst kind, no matter how many developers cheer it on. The docs are a contract, and if they were telling the truth, we have a responsibility to stand by them For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112288&group_id=5470 From noreply@sourceforge.net Sat Aug 19 03:50:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 19:50:33 -0700 Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue Message-ID: <200008190250.TAA31362@delerium.i.sourceforge.net> Bug #112289, was updated on 2000-Aug-18 19:50 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: NetBSD1.4.2 build issue Details: the recent fileobjects.c work done for large files (tmick) appears broken when compiled against NetBSD1.4.2. During the final link, you get the following output: gcc python.o ../libpython2.0.a -lutil -lm -o python fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 From noreply@sourceforge.net Sat Aug 19 04:09:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 20:09:32 -0700 Subject: [Python-bugs-list] [Bug #112288] os.path.commonprefix behaviour change. Message-ID: <200008190309.UAA12182@bush.i.sourceforge.net> Bug #112288, was updated on 2000-Aug-19 12:48 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 6 Summary: os.path.commonprefix behaviour change. Details: From python-dev: On 1.5.2, the behaviour was: >>> os.path.commonprefix(["../foo/bar", "../foo/spam"]) '../foo/' While since the change we have: '../foo' Note that the trailing slash has been dropped. [snip existing code that was broken by this change - much debate on python-dev ensues about which is the more desirable behaviour.] Tim adds: I agree this is Bad Damage, and should be fixed before 2.0b1 goes out. Can you enter a bug report? [more debate about what is the better behaviour, and that the old way was obviously broken] Tim again: commonprefix worked exactly as documented for at least 6 years and 5 months (which is when CVS shows Guido checking in ntpath.py with the character-based functionality), and got out of synch with the docs about 5 weeks ago when Skip changed to this other algorithm. Since the docs *did* match the code, there's no reason to believe the original author was confused, and no reason to believe users aren't relying on it (they've had over 6 years to gripe ). And Tim yet again: When the code and the docs have matched for more than 6 years, there is no bug by any rational definition of the term, and you can be certain that changing the library semantics then will break existing code. Presuming to change it anyway is developer arrogance of the worst kind, no matter how many developers cheer it on. The docs are a contract, and if they were telling the truth, we have a responsibility to stand by them For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112288&group_id=5470 From noreply@sourceforge.net Sat Aug 19 05:43:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 18 Aug 2000 21:43:10 -0700 Subject: [Python-bugs-list] [Bug #112288] os.path.commonprefix behaviour change. Message-ID: <200008190443.VAA02301@delerium.i.sourceforge.net> Bug #112288, was updated on 2000-Aug-18 22:48 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 6 Summary: os.path.commonprefix behaviour change. Details: From python-dev: On 1.5.2, the behaviour was: >>> os.path.commonprefix(["../foo/bar", "../foo/spam"]) '../foo/' While since the change we have: '../foo' Note that the trailing slash has been dropped. [snip existing code that was broken by this change - much debate on python-dev ensues about which is the more desirable behaviour.] Tim adds: I agree this is Bad Damage, and should be fixed before 2.0b1 goes out. Can you enter a bug report? [more debate about what is the better behaviour, and that the old way was obviously broken] Tim again: commonprefix worked exactly as documented for at least 6 years and 5 months (which is when CVS shows Guido checking in ntpath.py with the character-based functionality), and got out of synch with the docs about 5 weeks ago when Skip changed to this other algorithm. Since the docs *did* match the code, there's no reason to believe the original author was confused, and no reason to believe users aren't relying on it (they've had over 6 years to gripe ). And Tim yet again: When the code and the docs have matched for more than 6 years, there is no bug by any rational definition of the term, and you can be certain that changing the library semantics then will break existing code. Presuming to change it anyway is developer arrogance of the worst kind, no matter how many developers cheer it on. The docs are a contract, and if they were telling the truth, we have a responsibility to stand by them Follow-Ups: Date: 2000-Aug-19 00:43 By: tim_one Comment: A couple more points: + My only objection is to changing what the function does. I now know for a fact that some people at my last job were using at *as* a string function, just as it was documented to work. This means there are almost certainly many more people who will get burned too if commonprefix changes. + I wholly agree that it's not particularly useful for path manipulation, and encourage adding a *new* function that is useful for that. + Although Python-Dev doesn't seem able to agree yet on exactly what such a function should do (esp. whether to keep or toss trailing path separators). + I am not the BDFL. If Guido wants to piss off users by embracing the current incompatibility as-is, that's his call. But in that case this bug should morph into a gripe about the now-inaccurate library docs. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112288&group_id=5470 From noreply@sourceforge.net Sat Aug 19 18:09:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 19 Aug 2000 10:09:35 -0700 Subject: [Python-bugs-list] [Bug #112317] os.rename transparent handling of cross-filesystem issues Message-ID: <200008191709.KAA04803@bush.i.sourceforge.net> Bug #112317, was updated on 2000-Aug-19 10:09 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: os.rename transparent handling of cross-filesystem issues Details: On some systems (specifically, Linux), the rename system call will throw an EXDEV error if rename is used across filesystems. It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do). The benefits of this. . .getting rid of code like the following: try: os.rename('ff','/tmp/ff') except: open('/tmp/ff','w').write(open('ff','r').read()) os.unlink('ff') Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem. I took a quick look at posixmodule.c. A quick hack changes posix_2str's signature to the following: PyObject *args char *format int (*func)(const char*, const char *) int (*special_handler)(const char *, const char *) and the inner function to: if (res != 0) if ((! special_handler) || (*special_handler)(path1,path2)) return posix_error() Of course, then a smart copy routine (includes an unlink step). The most unclear thing at this point is what to do with the errno. Would a failure in the errorhandler report the original errno or its own errno??? Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112317&group_id=5470 From noreply@sourceforge.net Mon Aug 21 21:07:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 13:07:43 -0700 Subject: [Python-bugs-list] [Bug #112436] getopt regression test failure Message-ID: <200008212007.NAA08801@bush.i.sourceforge.net> Bug #112436, was updated on 2000-Aug-21 16:07 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: getopt regression test failure Details: When running an installed Python using the command line "python -c 'import test.autotest'", the getopt regression fails with this message: test_getopt test test_getopt failed -- Unread: 'Running tests on getopt.short_has_arg\012Running tests on getopt.long_has_args\012Running tests on getopt.do_shorts\012Running tests on getopt.do_longs\012Running tests on getopt.getopt\012Module getopt: tests completed successfully.\012' For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112436&group_id=5470 From noreply@sourceforge.net Mon Aug 21 21:19:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 13:19:47 -0700 Subject: [Python-bugs-list] [Bug #112436] getopt regression test failure Message-ID: <200008212019.NAA09251@bush.i.sourceforge.net> Bug #112436, was updated on 2000-Aug-21 16:07 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: getopt regression test failure Details: When running an installed Python using the command line "python -c 'import test.autotest'", the getopt regression fails with this message: test_getopt test test_getopt failed -- Unread: 'Running tests on getopt.short_has_arg\012Running tests on getopt.long_has_args\012Running tests on getopt.do_shorts\012Running tests on getopt.do_longs\012Running tests on getopt.getopt\012Module getopt: tests completed successfully.\012' Follow-Ups: Date: 2000-Aug-21 16:19 By: fdrake Comment: This also fails using "./python -c 'import test.autotest'" from the build area -- the important point seems to be running the test using import test.autotest instead of running test/regrtest.py as a script. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112436&group_id=5470 From noreply@sourceforge.net Mon Aug 21 23:33:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 15:33:36 -0700 Subject: [Python-bugs-list] [Bug #110911] parser module Message-ID: <200008212233.PAA03805@delerium.i.sourceforge.net> Bug #110911, was updated on 2000-Aug-02 05:53 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: parser module Details: This failure was first introduced in CVS revision 2.38 of parsermodule, by Fred Drake >>> from parser import * >>> sequence2ast(ast2list(parser.expr('foo(1)'))) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: Expected node type 12, got 312. >>> Follow-Ups: Date: 2000-Aug-02 09:57 By: fdrake Comment: Confirmed; assigned to myself. ------------------------------------------------------- Date: 2000-Aug-21 18:33 By: fdrake Comment: Fixed in parsermodule.c revision 2.50, and added a test suite including this specific example (& others!) to help keep this from happening again. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110911&group_id=5470 From noreply@sourceforge.net Tue Aug 22 00:47:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 16:47:32 -0700 Subject: [Python-bugs-list] [Bug #112436] getopt regression test failure Message-ID: <200008212347.QAA06256@delerium.i.sourceforge.net> Bug #112436, was updated on 2000-Aug-21 16:07 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: getopt regression test failure Details: When running an installed Python using the command line "python -c 'import test.autotest'", the getopt regression fails with this message: test_getopt test test_getopt failed -- Unread: 'Running tests on getopt.short_has_arg\012Running tests on getopt.long_has_args\012Running tests on getopt.do_shorts\012Running tests on getopt.do_longs\012Running tests on getopt.getopt\012Module getopt: tests completed successfully.\012' Follow-Ups: Date: 2000-Aug-21 16:19 By: fdrake Comment: This also fails using "./python -c 'import test.autotest'" from the build area -- the important point seems to be running the test using import test.autotest instead of running test/regrtest.py as a script. ------------------------------------------------------- Date: 2000-Aug-21 19:47 By: tim_one Comment: Changed to Fixed and Closed. Pinned on from test.test_support import verbose in test_getopt.py, which was causing a 2nd copy of test_support to get loaded with "the wrong" verbose value -- but only sometimes, depending on how you invoked regrtest! Guido fixed it (or at least said he did -- make sure you try it again!). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112436&group_id=5470 From noreply@sourceforge.net Tue Aug 22 06:05:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 21 Aug 2000 22:05:53 -0700 Subject: [Python-bugs-list] [Bug #112468] sre/pre bug Message-ID: <200008220505.WAA16580@delerium.i.sourceforge.net> Bug #112468, was updated on 2000-Aug-22 05:05 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: sre/pre bug Details: Compiling the simple pattern '(' with pre raises an exception while sre compiles it sucessfully. Further, the regex object that sre.compile returns will match any string. Using Python 1.6b1 (#0, Aug 7 2000, 12:30:24) [MSC 32 bit (Intel)] on win32, >>> import sre >>> regex_ = sre.compile('(') >>> regex_.pattern '(' >>> regex_.search('abc').group(0) '' while >>> import pre >>> regex_ = pre.compile('(') Traceback (most recent call last): File "", line 1, in ? File "C:\Python16\lib\pre.py", line 243, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('missing )', 1) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112468&group_id=5470 From noreply@sourceforge.net Tue Aug 22 12:01:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 04:01:57 -0700 Subject: [Python-bugs-list] [Bug #112472] wrong registry entry written by Wise installer Message-ID: <200008221101.EAA06292@bush.i.sourceforge.net> Bug #112472, was updated on 2000-Aug-22 13:01 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: wrong registry entry written by Wise installer Details: The WISE installer writes a wrong DLL-path into the registry: HKLM\Software\Python\PythonCore\2.0\Dll=\python20.dll instead of c:\winnt\system32\python20.dll (or whatever). Fix: Replace %_SYSDEST_%\Python20.dll with %_DLLDEST_%\Python20.dll. It seems 1.6b1 also has this problem. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112472&group_id=5470 From noreply@sourceforge.net Tue Aug 22 13:30:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 05:30:34 -0700 Subject: [Python-bugs-list] [Bug #112472] wrong registry entry written by Wise installer Message-ID: <200008221230.FAA31260@delerium.i.sourceforge.net> Bug #112472, was updated on 2000-Aug-22 11:01 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: wrong registry entry written by Wise installer Details: The WISE installer writes a wrong DLL-path into the registry: HKLM\Software\Python\PythonCore\2.0\Dll=\python20.dll instead of c:\winnt\system32\python20.dll (or whatever). Fix: Replace %_SYSDEST_%\Python20.dll with %_DLLDEST_%\Python20.dll. It seems 1.6b1 also has this problem. Follow-Ups: Date: 2000-Aug-22 12:30 By: gvanrossum Comment: Fixed for 2.0. For 1.6, I'm having CVS troubles, but I'll get over it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112472&group_id=5470 From noreply@sourceforge.net Tue Aug 22 13:34:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 05:34:08 -0700 Subject: [Python-bugs-list] [Bug #112468] sre/pre bug Message-ID: <200008221234.FAA31323@delerium.i.sourceforge.net> Bug #112468, was updated on 2000-Aug-22 05:05 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: sre/pre bug Details: Compiling the simple pattern '(' with pre raises an exception while sre compiles it sucessfully. Further, the regex object that sre.compile returns will match any string. Using Python 1.6b1 (#0, Aug 7 2000, 12:30:24) [MSC 32 bit (Intel)] on win32, >>> import sre >>> regex_ = sre.compile('(') >>> regex_.pattern '(' >>> regex_.search('abc').group(0) '' while >>> import pre >>> regex_ = pre.compile('(') Traceback (most recent call last): File "", line 1, in ? File "C:\Python16\lib\pre.py", line 243, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('missing )', 1) Follow-Ups: Date: 2000-Aug-22 12:34 By: gvanrossum Comment: According to Fredrik, this is a minor parsing bug in SRE. He'll fix it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112468&group_id=5470 From noreply@sourceforge.net Tue Aug 22 15:06:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 07:06:23 -0700 Subject: [Python-bugs-list] [Bug #112472] wrong registry entry written by Wise installer Message-ID: <200008221406.HAA02270@delerium.i.sourceforge.net> Bug #112472, was updated on 2000-Aug-22 11:01 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: wrong registry entry written by Wise installer Details: The WISE installer writes a wrong DLL-path into the registry: HKLM\Software\Python\PythonCore\2.0\Dll=\python20.dll instead of c:\winnt\system32\python20.dll (or whatever). Fix: Replace %_SYSDEST_%\Python20.dll with %_DLLDEST_%\Python20.dll. It seems 1.6b1 also has this problem. Follow-Ups: Date: 2000-Aug-22 12:30 By: gvanrossum Comment: Fixed for 2.0. For 1.6, I'm having CVS troubles, but I'll get over it. ------------------------------------------------------- Date: 2000-Aug-22 14:06 By: gvanrossum Comment: Note: according to Mark Hammond, this entry is not needed at all, so I've deleted it altogether. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112472&group_id=5470 From noreply@sourceforge.net Tue Aug 22 15:53:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 07:53:08 -0700 Subject: [Python-bugs-list] [Bug #112288] os.path.commonprefix behaviour change. Message-ID: <200008221453.HAA14490@bush.i.sourceforge.net> Bug #112288, was updated on 2000-Aug-18 22:48 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: None Bug Group: None Priority: 6 Summary: os.path.commonprefix behaviour change. Details: From python-dev: On 1.5.2, the behaviour was: >>> os.path.commonprefix(["../foo/bar", "../foo/spam"]) '../foo/' While since the change we have: '../foo' Note that the trailing slash has been dropped. [snip existing code that was broken by this change - much debate on python-dev ensues about which is the more desirable behaviour.] Tim adds: I agree this is Bad Damage, and should be fixed before 2.0b1 goes out. Can you enter a bug report? [more debate about what is the better behaviour, and that the old way was obviously broken] Tim again: commonprefix worked exactly as documented for at least 6 years and 5 months (which is when CVS shows Guido checking in ntpath.py with the character-based functionality), and got out of synch with the docs about 5 weeks ago when Skip changed to this other algorithm. Since the docs *did* match the code, there's no reason to believe the original author was confused, and no reason to believe users aren't relying on it (they've had over 6 years to gripe ). And Tim yet again: When the code and the docs have matched for more than 6 years, there is no bug by any rational definition of the term, and you can be certain that changing the library semantics then will break existing code. Presuming to change it anyway is developer arrogance of the worst kind, no matter how many developers cheer it on. The docs are a contract, and if they were telling the truth, we have a responsibility to stand by them Follow-Ups: Date: 2000-Aug-19 00:43 By: tim_one Comment: A couple more points: + My only objection is to changing what the function does. I now know for a fact that some people at my last job were using at *as* a string function, just as it was documented to work. This means there are almost certainly many more people who will get burned too if commonprefix changes. + I wholly agree that it's not particularly useful for path manipulation, and encourage adding a *new* function that is useful for that. + Although Python-Dev doesn't seem able to agree yet on exactly what such a function should do (esp. whether to keep or toss trailing path separators). + I am not the BDFL. If Guido wants to piss off users by embracing the current incompatibility as-is, that's his call. But in that case this bug should morph into a gripe about the now-inaccurate library docs. ------------------------------------------------------- Date: 2000-Aug-22 10:53 By: montanaro Comment: changes to posixpath.py, ntpath.py and dospath.py were reverted. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112288&group_id=5470 From noreply@sourceforge.net Tue Aug 22 23:46:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 15:46:12 -0700 Subject: [Python-bugs-list] [Bug #112521] re match becomes exponentially slow on larger inputs Message-ID: <200008222246.PAA22214@delerium.i.sourceforge.net> Bug #112521, was updated on 2000-Aug-22 22:46 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: re match becomes exponentially slow on larger inputs Details: The following code will run very slowly, using either python 1.5.2 or 1.6b1: ----8<---- import re s = """ arp ARP commands class Classifier commands dns DNS commands email Email commands event User event commands frame Frame Relay commands group Group configuration commands help On-Line help facility hl Host list configuration commands hostdb Host database commands image Image commands links Link commands look Withdraw touch access (go back to look-only access) measure Measurement commands mib MIB commands net Network statistics commands partition Bandwidth partition commands policy Policy commands reset Reset the PacketShaper """ r = re.compile ( r"\n\n(\s+.+\n)+\n\n$" ) mo = r.match ( s ) if mo: print "groups = %s" % mo.groups() else: print "no match" ----8<---- The above program takes 11 seconds to run on my system. FOr each line that I add in 's', the time DOUBLES. (And halves if I remove lines) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112521&group_id=5470 From noreply@sourceforge.net Wed Aug 23 00:33:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 16:33:21 -0700 Subject: [Python-bugs-list] [Bug #110606] ntpath.expandvars doesn't handle case properly (PR#162) Message-ID: <200008222333.QAA23858@delerium.i.sourceforge.net> Bug #110606, was updated on 2000-Jul-31 17:05 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: None Priority: 5 Summary: ntpath.expandvars doesn't handle case properly (PR#162) Details: Jitterbug-Id: 162 Submitted-By: dwr2@ix.netcom.com Date: Sun, 19 Dec 1999 08:38:21 -0500 (EST) Version: 1.5 OS: Windows 95 When accessing os.environ under Windows 95/NT/etc., lower-case environment variable names are automatically converted to upper-case before use. However, ntpath.expandvars does not accept lower-case variable names. This is inconsistent. This also happens in dospath.expandvars and may happen in os2path.expandvars. Here is a Python session demonstrating the problem: >>> import os >>> os.name 'nt' >>> os.environ['abc']='xyz' >>> os.environ['abc'] 'xyz' >>> os.path.expandvars('$abc') '' >>> os.path.expandvars('$ABC') 'xyz' >>> Note that you can access os.environ using a lower-case name, but you must use upper-case for os.path.expandvars (-->ntpath.expandvars). This can easily be fixed by changing "os.environ.has_key(var)" to "os.environ.has_key(string.upper(key))" in two places in each of ntpath.expandvars, dospath.expandvars, and possibly os2path.expandvars. Another solution would be to add the following function to os._Environ, in the "if name in ('os2', 'nt', 'dos')" block: def has_key(self, key): return UserDict.UserDict.has_key(self, string.upper(key)) The latter solution seems better to me, but I don't know the possible negative ramifications of making such a change to a class used in so many places. (On the other had, it is consistent with the definitions of _Environ.__getitem__ and _Environ.__setitem__.) Further argument that lower-case should be accepted in ntpath.expandvars: A DOS window opened in Windows 95 expands a lower-case variable name, despite the actual variable name being stored in upper-case: C:\WINDOWS>set abc=xyz C:\WINDOWS>set [...(most of variable list elided)...] ABC=xyz C:\WINDOWS>echo %abc% xyz ==================================================================== Audit trail: Mon Jan 17 09:05:54 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110606&group_id=5470 From noreply@sourceforge.net Wed Aug 23 04:19:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 20:19:17 -0700 Subject: [Python-bugs-list] [Bug #112521] re match becomes exponentially slow on larger inputs Message-ID: <200008230319.UAA31397@delerium.i.sourceforge.net> Bug #112521, was updated on 2000-Aug-22 18:46 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Summary: re match becomes exponentially slow on larger inputs Details: The following code will run very slowly, using either python 1.5.2 or 1.6b1: ----8<---- import re s = """ arp ARP commands class Classifier commands dns DNS commands email Email commands event User event commands frame Frame Relay commands group Group configuration commands help On-Line help facility hl Host list configuration commands hostdb Host database commands image Image commands links Link commands look Withdraw touch access (go back to look-only access) measure Measurement commands mib MIB commands net Network statistics commands partition Bandwidth partition commands policy Policy commands reset Reset the PacketShaper """ r = re.compile ( r"\n\n(\s+.+\n)+\n\n$" ) mo = r.match ( s ) if mo: print "groups = %s" % mo.groups() else: print "no match" ----8<---- The above program takes 11 seconds to run on my system. FOr each line that I add in 's', the time DOUBLES. (And halves if I remove lines) Follow-Ups: Date: 2000-Aug-22 23:19 By: tim_one Comment: By its very nature, this regular expression will match quickly when it *does* match, but consume enormous amounts of time when it doesn't match. Sorry, but "tough luck" is the only answer here. O'Reilly publishes a very good book, "Mastering Regular Expressions", by Jeffrey Friedl, that explains why in detail. Don't have time to write a book here , but, as a general hint, whenever you have nested repetition ("+" inside a "+" group, etc), unless you know exactly what you're doing you're going to cause *any* "NFA" regexp engine to take exponential time in the cases the regexp doesn't match. Bring it up on comp.lang.python! I'm sure someone will take the time to show you how to write the regexp in a way that works better. Or buy the book. Or don't use regexps for this problem to begin with. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112521&group_id=5470 From noreply@sourceforge.net Wed Aug 23 04:31:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 22 Aug 2000 20:31:12 -0700 Subject: [Python-bugs-list] [Bug #112521] re match becomes exponentially slow on larger inputs Message-ID: <200008230331.UAA10395@bush.i.sourceforge.net> Bug #112521, was updated on 2000-Aug-22 18:46 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Summary: re match becomes exponentially slow on larger inputs Details: The following code will run very slowly, using either python 1.5.2 or 1.6b1: ----8<---- import re s = """ arp ARP commands class Classifier commands dns DNS commands email Email commands event User event commands frame Frame Relay commands group Group configuration commands help On-Line help facility hl Host list configuration commands hostdb Host database commands image Image commands links Link commands look Withdraw touch access (go back to look-only access) measure Measurement commands mib MIB commands net Network statistics commands partition Bandwidth partition commands policy Policy commands reset Reset the PacketShaper """ r = re.compile ( r"\n\n(\s+.+\n)+\n\n$" ) mo = r.match ( s ) if mo: print "groups = %s" % mo.groups() else: print "no match" ----8<---- The above program takes 11 seconds to run on my system. FOr each line that I add in 's', the time DOUBLES. (And halves if I remove lines) Follow-Ups: Date: 2000-Aug-22 23:19 By: tim_one Comment: By its very nature, this regular expression will match quickly when it *does* match, but consume enormous amounts of time when it doesn't match. Sorry, but "tough luck" is the only answer here. O'Reilly publishes a very good book, "Mastering Regular Expressions", by Jeffrey Friedl, that explains why in detail. Don't have time to write a book here , but, as a general hint, whenever you have nested repetition ("+" inside a "+" group, etc), unless you know exactly what you're doing you're going to cause *any* "NFA" regexp engine to take exponential time in the cases the regexp doesn't match. Bring it up on comp.lang.python! I'm sure someone will take the time to show you how to write the regexp in a way that works better. Or buy the book. Or don't use regexps for this problem to begin with. ------------------------------------------------------- Date: 2000-Aug-22 23:31 By: tim_one Comment: BTW, try this: r = re.compile (r"\n\n(^[ \t][^\n]+\n)+\n\n$", re.MULTILINE) If you want to know why I did that, buy the book! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112521&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:26:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:26:50 -0700 Subject: [Python-bugs-list] [Bug #110674] memory bloat in binary file upload (PR#381) Message-ID: <200008231426.HAA21647@delerium.i.sourceforge.net> Bug #110674, was updated on 2000-Jul-31 21:13 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Summary: memory bloat in binary file upload (PR#381) Details: Jitterbug-Id: 381 Submitted-By: naris@ensim.com Date: Mon, 3 Jul 2000 21:29:25 -0400 (EDT) Version: 1.5.2 OS: RedHat 6.1 read_lines_to_outerboundary chews up memory. there's a while (1) loop that does a readline(), which is probably not good, as you could have a binary file that doesn't have an endline til the end, and thus readline would read the entire file into memory. i did the following: dd'd a 100MB /dev/zero file and used zope to upload it. it chewed up a large amount of memory. there seems to be bug reports about text files and windows systems (and needing to use python -u), but this problem is unrelated. i am using a unix browser -> unix web server. ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110674&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:28:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:28:36 -0700 Subject: [Python-bugs-list] [Bug #110599] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Message-ID: <200008231428.HAA21678@delerium.i.sourceforge.net> Bug #110599, was updated on 2000-Jul-31 21:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Details: Jitterbug-Id: 102 Submitted-By: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Date: Mon, 11 Oct 1999 13:00:07 +0200 Version: None OS: None 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 **************************************************************************** ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 21:05 By: none Comment: From: Jeremy Hylton Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Tue, 12 Oct 1999 12:04:42 -0400 (EDT) >>>>> "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 ------------------------------------------------------- Date: 2000-Jul-31 21:05 By: none Comment: From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 09:19:44 +0200 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 ------------------------------------------------------- Date: 2000-Jul-31 21:05 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 08:57:25 -0400 > 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/) ------------------------------------------------------- Date: 2000-Jul-31 21:05 By: none Comment: From: "=?iso-8859-2?B?VmxhZGlt7XIgQmVuZbk=?=" Subject: Re: [Python-bugs-list] bug (Incorrect signal processing) - Python 1.5.2 (PR#102) Date: Wed, 13 Oct 1999 16:34:39 +0200 >... >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 ------------------------------------------------------- Date: 2000-Aug-10 18:45 By: gvanrossum Comment: Sorry, I can't take this. It's an issue though! There are a bunch of signal related bugs in Linux... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110599&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:29:55 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:29:55 -0700 Subject: [Python-bugs-list] [Bug #110609] Operator breakage with long int operands (PR#187) Message-ID: <200008231429.HAA21741@delerium.i.sourceforge.net> Bug #110609, was updated on 2000-Jul-31 21:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Operator breakage with long int operands (PR#187) Details: Jitterbug-Id: 187 Submitted-By: aa8vb@yahoo.com Date: Mon, 24 Jan 2000 11:19:11 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5 This came up a few weeks ago, and bit again in the dumbdbm module last week. In the dumbdbm module in 1.5.2: '\0'*(npos-pos) (npos-pos) on some OSs will be a long int. However, the '*' operator won't handle a long int. I can't think of a reason why 'a'*10L should be invalid, for example. At issue a few weeks ago was long ints and the '%' operator. For example: >>> str( 0x80000000L ) '2147483648L' >>> "%ld" % 0x80000000L OverflowError: long int too long to convert >>> hex( 0x80000000L ) '0x80000000L' >>> "%lX" % 0x80000000L OverflowError: long int too long to convert Couldn't % use hex() and str() under the hood, for instance? ==================================================================== Audit trail: Mon Jan 24 14:28:42 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110609&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:30:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:30:36 -0700 Subject: [Python-bugs-list] [Bug #110607] Telnet close (PR#181) Message-ID: <200008231430.HAA21750@delerium.i.sourceforge.net> Bug #110607, was updated on 2000-Jul-31 21:05 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Telnet close (PR#181) Details: Jitterbug-Id: 181 Submitted-By: cha@tandberg.no Date: Wed, 12 Jan 2000 09:49:29 -0500 (EST) Version: 1.5.2 OS: Windows NT4.0 The telnet.close() object does not close the telnet session. Session will only be closed after a timeout on the remote side. ==================================================================== Audit trail: Wed Jan 12 18:29:38 2000 guido changed notes Wed Jan 12 18:29:38 2000 guido changed notification Wed Jan 12 18:29:38 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110607&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:31:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:31:23 -0700 Subject: [Python-bugs-list] [Bug #110611] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Message-ID: <200008231431.HAA21755@delerium.i.sourceforge.net> Bug #110611, was updated on 2000-Jul-31 21:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Signal processing bug (Linux threads, readline, whatever else) (PR#196) Details: Jitterbug-Id: 196 Submitted-By: Gregor Hoffleit Date: Tue, 1 Feb 2000 14:43:09 +0100 Version: None OS: None --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-- ==================================================================== Audit trail: Mon Feb 07 12:38:12 2000 guido changed notes Mon Feb 07 12:38:12 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 21:05 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Wed, 2 Feb 2000 03:04:04 -0500 [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. ------------------------------------------------------- Date: 2000-Jul-31 21:05 By: none Comment: From: Gregor Hoffleit Subject: RE: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Wed, 2 Feb 2000 14:25:07 +0100 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 ------------------------------------------------------- Date: 2000-Jul-31 21:05 By: none Comment: From: Gregor Hoffleit Subject: Returned mail: User unknown Date: Thu, 3 Feb 2000 11:46:44 +0100 (MET) 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-- ------------------------------------------------------- Date: 2000-Jul-31 21:05 By: none Comment: From: Gregor Hoffleit Subject: Re: [Python-bugs-list] Signal processing bug (Linux threads, readline, whatever else) (PR#196) Date: Fri, 11 Feb 2000 14:52:42 +0100 --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-- ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110611&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:32:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:32:08 -0700 Subject: [Python-bugs-list] [Bug #110598] Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101) Message-ID: <200008231432.HAA21856@delerium.i.sourceforge.net> Bug #110598, was updated on 2000-Jul-31 21:05 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101) Details: Jitterbug-Id: 101 Submitted-By: flight@mathi.uni-heidelberg.de Date: Mon, 11 Oct 1999 15:10:37 +0200 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 ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110598&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:24:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:24:08 -0700 Subject: [Python-bugs-list] [Bug #112558] dictionary lookup does not check exceptions Message-ID: <200008231424.HAA21508@delerium.i.sourceforge.net> Bug #112558, was updated on 2000-Aug-23 14:24 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 9 Summary: dictionary lookup does not check exceptions Details: class BadDictKey: def __hash__(self): return hash(self.__class__) def __cmp__(self, other): if isinstance(other, self.__class__): print "raising error" raise RuntimeError, "gotcha" return other The dict lookup code does not check for hash or cmp functions raising an exception. This can lead to a variety of bogus behavior; e.g. the uncaught exception is noticed and raised for the next line. >>> d = {} >>> x1 = BadDictKey() >>> x2 = BadDictKey() >>> d[x1] = 1 >>> d[x2] = 2 raising error >>> print d.keys() Traceback (most recent call last): File "/tmp/dicterr.py", line 8, in __cmp__ raise RuntimeError, "gotcha" RuntimeError: gotcha For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112558&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:24:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:24:57 -0700 Subject: [Python-bugs-list] [Bug #110667] select module: Bug in select.select() (PR#365) Message-ID: <200008231424.HAA21533@delerium.i.sourceforge.net> Bug #110667, was updated on 2000-Jul-31 21:12 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Summary: select module: Bug in select.select() (PR#365) Details: Jitterbug-Id: 365 Submitted-By: r32813@email.sps.mot.com Date: Wed, 21 Jun 2000 12:00:54 -0400 (EDT) Version: 1.5.2 OS: AIX 4.3.1 The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when this command was run:- select.select(waitList, [], [], timeWait) This command worked fine in Python 1.5.1 build and also fine on Python 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on 2 AIX machines that we have. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 21:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Wed, 21 Jun 2000 17:08:33 -0500 > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > this command was run:- > > select.select(waitList, [], [], timeWait) > > This command worked fine in Python 1.5.1 build and also fine on Python > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > 2 AIX machines that we have. Could you give us some more information? You're indicating that it's platform specific; we don't have an AIX box. I'm guessing it's not obvious that our code is wrong, but it may violate some guidelines given by AIX manuals. If we ever want to fix this, we'll need to interact with you. the first thing we need is a decent stack trace; we'll take it from there. If you could investigate this on your own and come up with a fix, that would probably the best solution... --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 21:01 By: none Comment: From: "Wahmeng Wong" Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Thu, 22 Jun 2000 19:02:11 -0700 This is a multi-part message in MIME format. --------------F9E74BCE6963FE221E423528 Content-Type: multipart/alternative; boundary="------------FF8E270086909CA1DBDDA697" --------------FF8E270086909CA1DBDDA697 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido, Below is the dbx information from the coredump. This only occurs when the select.select() function is used within a thread. This same error occurs on both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not occur on AIX 4.1.4. $ dbx -I ./Modules ./python core Type 'help' for help. reading symbolic information ... [using memory image in core] Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" ($t2) 235 PyObject *tout = Py_None; We have been able to reproduce the coredump by modifying the test_select.py to perform the test within a thread. Attached is the modified file called test_thread_select.py. Just place this file in the Lib/test directory to see this problem. Thanks for all your help. Regards, Wah Meng Guido van Rossum wrote: > > The python 1.5.2 built on AIX 4.3.1.0 platform created a coredump when > > this command was run:- > > > > select.select(waitList, [], [], timeWait) > > > > This command worked fine in Python 1.5.1 build and also fine on Python > > 1.5.2 built on HP 10.2. It just didn't work in AIX 4.3.1.0 build on > > 2 AIX machines that we have. > > Could you give us some more information? You're indicating that it's > platform specific; we don't have an AIX box. I'm guessing it's not > obvious that our code is wrong, but it may violate some guidelines > given by AIX manuals. If we ever want to fix this, we'll need to > interact with you. the first thing we need is a decent stack trace; > we'll take it from there. > > If you could investigate this on your own and come up with a fix, that > would probably the best solution... > > --Guido van Rossum (home page: http://www.python.org/~guido/) --------------FF8E270086909CA1DBDDA697 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Guido,

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

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

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

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

Thanks for all your help.

Regards,
Wah Meng

Guido van Rossum wrote:

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

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

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

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

--------------FF8E270086909CA1DBDDA697-- --------------F9E74BCE6963FE221E423528 Content-Type: application/x-unknown-content-type-Python.File; name="test_thread_select.py" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="test_thread_select.py" IyBUZXN0aW5nIHNlbGVjdCBtb2R1bGUNCmZyb20gdGVzdF9zdXBwb3J0IGltcG9ydCB2ZXJi b3NlDQppbXBvcnQgc2VsZWN0LCB0aHJlYWQsIFF1ZXVlDQppbXBvcnQgb3MNCg0KIyB0ZXN0 IHNvbWUga25vd24gZXJyb3IgY29uZGl0aW9ucw0KdHJ5Og0KICAgIHJmZCwgd2ZkLCB4ZmQg PSBzZWxlY3Quc2VsZWN0KDEsIDIsIDMpDQpleGNlcHQgVHlwZUVycm9yOg0KICAgIHBhc3MN CmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJvciBleGNlcHRpb24gbm90IHJh aXNlZCcNCg0KY2xhc3MgTm9wZToNCiAgICBwYXNzDQoNCmNsYXNzIEFsbW9zdDoNCiAgICBk ZWYgZmlsZW5vKHNlbGYpOg0KICAgICAgICByZXR1cm4gJ2ZpbGVubycNCiAgICANCnRyeToN CiAgICByZmQsIHdmZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbTm9wZSgpXSwgW10sIFtdKQ0K ZXhjZXB0IFR5cGVFcnJvcjoNCiAgICBwYXNzDQplbHNlOg0KICAgIHByaW50ICdleHBlY3Rl ZCBUeXBlRXJyb3IgZXhjZXB0aW9uIG5vdCByYWlzZWQnDQoNCnRyeToNCiAgICByZmQsIHdm ZCwgeGZkID0gc2VsZWN0LnNlbGVjdChbQWxtb3N0KCldLCBbXSwgW10pDQpleGNlcHQgVHlw ZUVycm9yOg0KICAgIHBhc3MNCmVsc2U6DQogICAgcHJpbnQgJ2V4cGVjdGVkIFR5cGVFcnJv ciBleGNlcHRpb24gbm90IHJhaXNlZCcNCg0KDQpkZWYgdGVzdChxKToNCiAgICAgICAgaW1w b3J0IHN5cw0KICAgICAgICBpZiBzeXMucGxhdGZvcm1bOjNdIGluICgnd2luJywgJ21hYycs ICdvczInKToNCiAgICAgICAgICAgICAgICBpZiB2ZXJib3NlOg0KICAgICAgICAgICAgICAg ICAgICAgICAgcHJpbnQgIkNhbid0IHRlc3Qgc2VsZWN0IGVhc2lseSBvbiIsIHN5cy5wbGF0 Zm9ybQ0KICAgICAgICAgICAgICAgIHJldHVybg0KICAgICAgICBjbWQgPSAnZm9yIGkgaW4g MCAxIDIgMyA0IDUgNiA3IDggOTsgZG8gZWNobyB0ZXN0aW5nLi4uOyBzbGVlcCAxOyBkb25l Jw0KICAgICAgICBwID0gb3MucG9wZW4oY21kLCAncicpDQogICAgICAgIGZvciB0b3V0IGlu ICgwLCAxLCAyLCA0LCA4LCAxNikgKyAoTm9uZSwpKjEwOg0KICAgICAgICAgICAgICAgIGlm IHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICBwcmludCAndGltZW91dCA9Jywg dG91dA0KICAgICAgICAgICAgICAgIHJmZCwgd2ZkLCB4ZmQgPSBzZWxlY3Quc2VsZWN0KFtw XSwgW10sIFtdLCB0b3V0KQ0KIyMgICAgICAgICAgICAgIHByaW50IHJmZCwgd2ZkLCB4ZmQN CiAgICAgICAgICAgICAgICBpZiAocmZkLCB3ZmQsIHhmZCkgPT0gKFtdLCBbXSwgW10pOg0K ICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWUNCiAgICAgICAgICAgICAgICBpZiAo cmZkLCB3ZmQsIHhmZCkgPT0gKFtwXSwgW10sIFtdKToNCiAgICAgICAgICAgICAgICAgICAg ICAgIGxpbmUgPSBwLnJlYWRsaW5lKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIGlmIHZl cmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByaW50IGBsaW5lYA0K ICAgICAgICAgICAgICAgICAgICAgICAgaWYgbm90IGxpbmU6DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlmIHZlcmJvc2U6DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcHJpbnQgJ0VPRicNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYnJlYWsNCiAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQogICAgICAg ICAgICAgICAgcHJpbnQgJ0hlaD8nDQogICAgICAgIHAuY2xvc2UoKQ0KICAgICAgICBxLnB1 dCgxKQ0KDQoNCnEgPSBRdWV1ZS5RdWV1ZSgxKQ0KdGhyZWFkLnN0YXJ0X25ld190aHJlYWQo dGVzdCwocSwpKQ0KI3dhaXQgZm9yIHRocmVhZCB0byBjb21wbGV0ZSB0ZXN0IGZ1bmN0aW9u DQpkb25lID0gcS5nZXQoKQ0KcHJpbnQgJ3RocmVhZCBjb21wbGV0ZWQgdGVzdCwgZXhpdGlu ZycNCg0K --------------F9E74BCE6963FE221E423528-- ------------------------------------------------------- Date: 2000-Aug-01 21:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] select module: Bug in select.select() (PR#365) Date: Fri, 23 Jun 2000 11:01:40 -0500 > Below is the dbx information from the coredump. This only occurs when the > select.select() function is used within a thread. This same error occurs on > both Python 1.5.1 and Python 1.5.2 when AIX 4.3.1. This problem does not > occur on AIX 4.1.4. > > $ dbx -I ./Modules ./python core > Type 'help' for help. > reading symbolic information ... > [using memory image in core] > > Segmentation fault in initselect at line 235 in file "Modules/selectmodule.c" > ($t2) > 235 PyObject *tout = Py_None; Thanks. Could you do this again and also type the "bt" (backtrace) command? That would perhaps be more helpful. We can't reproduce this here since we don't have access to AIX! (Even if we ha,d it would be low priority :-( ). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110667&group_id=5470 From noreply@sourceforge.net Wed Aug 23 15:53:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 07:53:19 -0700 Subject: [Python-bugs-list] [Bug #110616] source file stays open after parsing is done (PR#209) Message-ID: <200008231453.HAA00616@bush.i.sourceforge.net> Bug #110616, was updated on 2000-Jul-31 21:06 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 5 Summary: source file stays open after parsing is done (PR#209) Details: Jitterbug-Id: 209 Submitted-By: Guido van Rossum Date: Tue, 22 Feb 2000 10:42:17 -0500 Version: None OS: None 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 ==================================================================== Audit trail: Wed Feb 23 21:30:38 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110616&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:22:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:22:44 -0700 Subject: [Python-bugs-list] [Bug #110641] KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Message-ID: <200008231722.KAA05978@bush.i.sourceforge.net> Bug #110641, was updated on 2000-Jul-31 21:09 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: KeyboardInterrupt while waiting for sys.ps2 input kills interpreter (PR#309) Details: Jitterbug-Id: 309 Submitted-By: skip@mojam.com Date: Fri, 28 Apr 2000 17:00:40 -0400 (EDT) Version: 1.5.2, 1.6a2 OS: Linux If you hit Ctrl-C while the Python interpreter is sitting at the ps2 prompt the interpreter exits instead of returning you to the top-level prompt. % python Python 1.5.2+ (#12, Feb 17 2000, 14:52:05) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... % PYTHONSTARTUP= ./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... When run under gdb's control, you can see what's happening: % gdb ./python GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-mandrake-linux"... (gdb) set env PYTHONSTARTUP "" (gdb) run Starting program: /home/beluga/skip/src/python/dist/src/./python Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> if 1: ... Program received signal SIGINT, Interrupt. 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) bt #0 0x4013bf14 in __libc_read () from /lib/libc.so.6 (gdb) c Continuing. File "", line 2 ^ SyntaxError: invalid syntax >>> It appears that SIGINT isn't handled properly when awaiting console input in certain circumstances. If you can entice the program to continue, things work okay. I don't know interrupt handling from a hole in the ground or I'd investigate further. It is quite annoying, especially considering that Python's input history isn't continuous across sessions... Skip ==================================================================== Audit trail: Mon May 22 17:23:42 2000 guido changed notes Mon May 22 17:23:42 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 21:40 By: twouters Comment: This seems to be platform specific: On Linux, up-to-date CVS compile, this is reproducible. On BSDI 4.1, however, with an almost-up-to-date CVS compile, ^C doesn't exit the interpreter. ------------------------------------------------------- Date: 2000-Aug-06 11:57 By: twouters Comment: Oh, and it's also definately readline-related. (without readline compiled in, the bug doesn't get triggered, in any case.) ------------------------------------------------------- Date: 2000-Aug-09 15:59 By: twouters Comment: I've been toying with this, and the problem *is* readline. Readline overrides a number of signal handlers, in order to do cleanup when exiting, and apparently does not restore them on exit :-S The signals readline 'overrides' the handlers of are: SIGINT SIGALRM SIGTSTP SIGTTOU SIGTTIN SIGTERM SIGWINCH Which means that the signal handlers for these signals *vanish* when using readline. Interactive mode uses readline, but scripts can themselves, too. I'm not sure why this isn't showing on BSDI, but it might have something to do with the BSD vs the SysV signal handling routines. I'm also not sure if it's possible to fix this problem; it might be a bug in readline, or it might be documented behaviour. But I wasn't able to find a reference to signal handling in the 2.2.1 readline info files. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110641&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:24:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:24:17 -0700 Subject: [Python-bugs-list] [Bug #110617] IDLE and -t (PR#213) Message-ID: <200008231724.KAA06098@bush.i.sourceforge.net> Bug #110617, was updated on 2000-Jul-31 21:06 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 3 Summary: IDLE and -t (PR#213) Details: Jitterbug-Id: 213 Submitted-By: aa8vb@yahoo.com Date: Fri, 25 Feb 2000 07:36:01 -0500 (EST) Version: 1.5.2 (w/ IDLE 0.5) OS: IRIX 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". ==================================================================== Audit trail: Tue Mar 07 14:41:55 2000 guido changed notes Tue Mar 07 14:41:55 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 21:06 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Fri, 25 Feb 2000 08:26:32 -0500 > 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/) ------------------------------------------------------- Date: 2000-Jul-31 21:06 By: none Comment: From: Randall Hopper Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 28 Feb 2000 07:25:31 -0500 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 ------------------------------------------------------- Date: 2000-Jul-31 21:06 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 28 Feb 2000 08:16:48 -0500 > |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/) ------------------------------------------------------- Date: 2000-Jul-31 21:06 By: none Comment: From: Randall Hopper Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Tue, 29 Feb 2000 14:26:37 -0500 --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-- ------------------------------------------------------- Date: 2000-Jul-31 21:06 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Wed, 01 Mar 2000 09:21:41 -0500 Randall, Thanks for your enlightenment. I looked at your example, and it works; but I need more, because IDLE creates windows using Toplevel(), not using Tk(). (Using Tk() would create a new Tcl interpreter for each window, which wastes time and memory resources, and re-reads the ~/..py file each time.) I've experimented with xprop a bit, and I'm not getting results I like. If I write root = Tk(className="foo"), WM_CLASS is "foo", "Foo". Them if I write top = Toplevel(root), WM_CLASS for that window is "1234567", "Toplevel". If I try top = Toplevel(root, name="bar"), I get "bar", "Toplevel". Shouldn't I be able to set the second component of WM_CLASS somehow? Got any ideas? If you can send me a patch, that would be greatly appreciated! --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 21:06 By: none Comment: From: Randall Hopper Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 6 Mar 2000 08:50:29 -0500 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Guido van Rossum: |Thanks for your enlightenment. I looked at your example, and it |works; but I need more, because IDLE creates windows using Toplevel(), |not using Tk(). (Using Tk() would create a new Tcl interpreter for |each window, which wastes time and memory resources, and re-reads the |~/..py file each time.) | |I've experimented with xprop a bit, and I'm not getting results I |like. If I write root = Tk(className="foo"), WM_CLASS is "foo", |"Foo". Them if I write top = Toplevel(root), WM_CLASS for that window |is "1234567", "Toplevel". If I try top = Toplevel(root, name="bar"), |I get "bar", "Toplevel". Shouldn't I be able to set the second |component of WM_CLASS somehow? | |Got any ideas? Sorry about that last message. This issue is very closely related to the resource loading issue on idle-dev, but not the same. Once the small change below is in-place (to solve this problem), the platform-independent Tkinter methods for resource loading can be used to solve the idle-dev problem, if desired. Research indicates that the Tk-ism for setting Toplevel classes is: "toplevel .mytop -class classname" So the Tkinter syntax is: top1 = Toplevel( root, class_=classname ) The attached test app demonstrates this. I verified that I am able to set X resources for these windows using the class name "Idle". -- Randall Hopper aa8vb@yahoo.com --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tk_class.py" from Tkinter import * CLASSNAME = "Idle" root = Tk( className=CLASSNAME ) root.wm_withdraw() # A toplevel with a WM_CLASS top1 = Toplevel( root, class_=CLASSNAME ) label1 = Label( top1, text="Toplevel 1" ) label1.pack() # Another one top2 = Toplevel( root, class_=CLASSNAME ) label2 = Label( top2, text="Toplevel 2" ) label2.pack() root.mainloop() --MGYHOYXEY6WxJCY8-- ------------------------------------------------------- Date: 2000-Jul-31 21:06 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE and -t (PR#213) Date: Mon, 06 Mar 2000 09:11:30 -0500 > Sorry about that last message. This issue is very closely related to the > resource loading issue on idle-dev, but not the same. Once the small > change below is in-place (to solve this problem), the platform-independent > Tkinter methods for resource loading can be used to solve the idle-dev > problem, if desired. See my response in idle-dev :-) Of course the Tk options can still be used for changing things that the config file or prefs dialog doesn't support. > Research indicates that the Tk-ism for setting Toplevel classes is: > > "toplevel .mytop -class classname" > > So the Tkinter syntax is: > > top1 = Toplevel( root, class_=classname ) > > The attached test app demonstrates this. I verified that I am able to set > X resources for these windows using the class name "Idle". OK, I'll try to support this! --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110617&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:25:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:25:11 -0700 Subject: [Python-bugs-list] [Bug #110841] idle dosnt recompile modules changed externally (PR#308) Message-ID: <200008231725.KAA06111@bush.i.sourceforge.net> Bug #110841, was updated on 2000-Aug-01 21:15 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: idle dosnt recompile modules changed externally (PR#308) Details: Jitterbug-Id: 308 Submitted-By: jnc@ecs.soton.ac.uk Date: Fri, 28 Apr 2000 13:41:55 -0400 (EDT) Version: 1.5.2 OS: windows 98 Consider two scripts showbug.py ===== import bug1 bug1.bug() ===== and bug1.py ===== def bug(): print 'Bug 5' ===== both in the same directory. load showbug.py into idle (0.5) and runit with F5, the bug function prints Bug 5 Now change bug1.py outside or even with idle, save it. dates on disk now show bug1.py is newer than bug1.pyc rerun showbug.py pressing F5 or ctrl-F5 it still prints Bug 5. I dont think this behaviour is what is required.Certainly it cost me most of the afternoon tracking down non-existant problems in my code. John Carter ==================================================================== Audit trail: Mon May 22 17:23:04 2000 guido changed notes Mon May 22 17:23:04 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 21:15 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] idle dosnt recompile modules changed externally (PR#308) Date: Fri, 28 Apr 2000 14:45:30 -0400 > Consider two scripts > > showbug.py > ===== > > import bug1 > > bug1.bug() > ===== > and bug1.py > ===== > def bug(): > print 'Bug 5' > ===== > > both in the same directory. > > load showbug.py into idle (0.5) and runit with F5, > > the bug function prints Bug 5 > > Now change bug1.py outside or even with idle, save it. > dates on disk now show bug1.py is newer than bug1.pyc > > rerun showbug.py pressing F5 or ctrl-F5 > > it still prints Bug 5. > > I dont think this behaviour is what is required.Certainly it cost me most > of the afternoon tracking down non-existant problems in my code. I appreciate the bug report. The current definitions of running a script and importing a module all conspire to get this behavior. We're working on a major change where IDLE executes your script in a separate process that is created from scratch each time you use [ctrl-]F5, and then it will go away. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 21:15 By: none Comment: This is all explainable, but I agree it's bad for the user. We'll fix it by running scripts in a new process. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110841&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:25:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:25:48 -0700 Subject: [Python-bugs-list] [Bug #110704] IDLE (PR#400) Message-ID: <200008231725.KAA06125@bush.i.sourceforge.net> Bug #110704, was updated on 2000-Jul-31 21:29 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: Platform-specific Priority: 3 Summary: IDLE (PR#400) Details: Jitterbug-Id: 400 Submitted-By: crislipm@earthlink.net Date: Sun, 16 Jul 2000 20:40:24 -0400 (EDT) Version: 1.5.2 OS: Linuxppc, Suse dist more for curiosity/FYI Using 1.5.2 (the version that came with the suse linuxppc) and IDLE 0.5 on an ibook (version 2). IDLE causes the keyboard to stop working (I am not certain which, if any action, causes this, but it is reproducable) and the problem continues when I warm boot back to the MAC OS. Have to do a cold boot to get keyboard to respond again. ==================================================================== Audit trail: Mon Jul 24 18:30:07 2000 jeremy changed notes Mon Jul 24 18:30:07 2000 jeremy moved from incoming to platformbug For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110704&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:25:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:25:57 -0700 Subject: [Python-bugs-list] [Bug #110660] IDLE-0.5 ctrl-F5 (PR#355) Message-ID: <200008231725.KAA06138@bush.i.sourceforge.net> Bug #110660, was updated on 2000-Jul-31 21:11 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 3 Summary: IDLE-0.5 ctrl-F5 (PR#355) Details: Jitterbug-Id: 355 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 11:30:14 -0400 (EDT) Version: yesterday's CVS OS: Solaris 2.6 If you type ctrl-f5 to run a script twice in sucession, IDLE will incorrectly pop up a window saying "Not Saved. Please Save First." If you save (even though you haven't changed anything, and even though there are no asterisks around the window title), then ctrl-f5 will work again. This *doesn't* happen if you run the script twice in succession from the menu. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 21:01 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 13 Jun 2000 11:55:09 -0400 Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under Windows, but darned hard to see why that would matter. Can anyone else try this under Solaris 2.6? May have something to do with the specific script you're running, Greg; e.g., does it happen if the script file contains just print "Hi!" ? > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > Sent: Tuesday, June 13, 2000 11:30 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > Full_Name: Greg Kochanski > Version: yesterday's CVS > OS: Solaris 2.6 > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > If you type ctrl-f5 to run a script twice in sucession, > IDLE will incorrectly pop up a window saying > "Not Saved. Please Save First." > > If you save (even though you haven't changed anything, > and even though there are no asterisks around the window > title), then ctrl-f5 will work again. > > This *doesn't* happen if you run the script twice in > succession from the menu. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > ------------------------------------------------------- Date: 2000-Aug-01 21:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 16:42:57 -0500 I think I understand this. It's happened to me too. Pressing ^F5 changes the focus to the PyShell window. Pressing ^F5 again then indeed complains about that window being unsaved. --Guido van Rossum (home page: http://www.python.org/~guido/) [Tim] > Pretty mysterious! Doesn't happen under IDLE 0.5 for me. Running under > Windows, but darned hard to see why that would matter. Can anyone else try > this under Solaris 2.6? May have something to do with the specific script > you're running, Greg; e.g., does it happen if the script file contains just > > print "Hi!" > > ? > > > -----Original Message----- > > From: python-bugs-list-admin@python.org > > [mailto:python-bugs-list-admin@python.org]On Behalf Of gpk@bell-labs.com > > Sent: Tuesday, June 13, 2000 11:30 AM > > To: python-bugs-list@python.org > > Cc: bugs-py@python.org > > Subject: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) > > > > > > Full_Name: Greg Kochanski > > Version: yesterday's CVS > > OS: Solaris 2.6 > > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > > > > > If you type ctrl-f5 to run a script twice in sucession, > > IDLE will incorrectly pop up a window saying > > "Not Saved. Please Save First." > > > > If you save (even though you haven't changed anything, > > and even though there are no asterisks around the window > > title), then ctrl-f5 will work again. > > > > This *doesn't* happen if you run the script twice in > > succession from the menu. > > > > > > > > _______________________________________________ > > Python-bugs-list maillist - Python-bugs-list@python.org > > http://www.python.org/mailman/listinfo/python-bugs-list > > > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list ------------------------------------------------------- Date: 2000-Aug-01 21:01 By: none Comment: From: Greg Kochanski Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 17:25:37 -0400 Guido van Rossum wrote: > > I think I understand this. It's happened to me too. Pressing ^F5 > changes the focus to the PyShell window. Pressing ^F5 again then > indeed complains about that window being unsaved. > > --Guido van Rossum (home page: http://www.python.org/~guido/) Ah. Sure enough. Perhaps the best thing to do is just to have the little error message explain which window is unsaved. Include the title of the unsaved window in the error box, maybe. I'd be happy to send a patch, but the paperwork would be terrible... ------------------------------------------------------- Date: 2000-Aug-01 21:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] IDLE-0.5 ctrl-F5 (PR#355) Date: Tue, 20 Jun 2000 18:10:35 -0500 > > I think I understand this. It's happened to me too. Pressing ^F5 > > changes the focus to the PyShell window. Pressing ^F5 again then > > indeed complains about that window being unsaved. > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > Ah. Sure enough. Perhaps the best thing to do > is just to have the little error message explain > which window is unsaved. Include the title > of the unsaved window in the error box, maybe. > > I'd be happy to send a patch, but the paperwork > would be terrible... No need for paperwork, just the disclaimer text. But I think the better patch would be to make PyShell a special case and make it rerun the last window that had the focus. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110660&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:26:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:26:03 -0700 Subject: [Python-bugs-list] [Bug #110618] IDLE: Modifying argv prevents source of ~/.idle.py (PR#219) Message-ID: <200008231726.KAA06143@bush.i.sourceforge.net> Bug #110618, was updated on 2000-Jul-31 21:06 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 3 Summary: IDLE: Modifying argv prevents source of ~/.idle.py (PR#219) Details: Jitterbug-Id: 219 Submitted-By: aa8vb@yahoo.com Date: Mon, 28 Feb 2000 07:49:55 -0500 (EST) Version: 1.5.2 OS: IRIX 6.5.6f (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. ==================================================================== Audit trail: Tue Mar 07 14:38:27 2000 guido changed notes Tue Mar 07 14:38:27 2000 guido changed notification Tue Mar 07 14:38:27 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110618&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:26:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:26:23 -0700 Subject: [Python-bugs-list] [Bug #110659] IDLE-0.5 copy command (PR#354) Message-ID: <200008231726.KAA06154@bush.i.sourceforge.net> Bug #110659, was updated on 2000-Jul-31 21:11 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 3 Summary: IDLE-0.5 copy command (PR#354) Details: Jitterbug-Id: 354 Submitted-By: gpk@bell-labs.com Date: Tue, 13 Jun 2000 10:05:35 -0400 (EDT) Version: 1.6a2+ OS: Solaris sparc 2.6 Alt-w is advertised to copy the selected text. It doesn't. It pops up the 'window' menu. However, even if you are in the 'edit' menu, alt-w apparently does nothing. I can select text, do alt-E alt-W, move the pointer, then do ctrl-Y, and nothing pops up. By the way, 'ctl-U ctl-U ctl-S' is an absurdly long sequence for something as common as searching for text. ==================================================================== Audit trail: Tue Jul 11 08:26:00 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110659&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:26:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:26:28 -0700 Subject: [Python-bugs-list] [Bug #110656] IDLE goto file/line (PR#352) Message-ID: <200008231726.KAA06158@bush.i.sourceforge.net> Bug #110656, was updated on 2000-Jul-31 21:11 Here is a current snapshot of the bug. Project: Python Category: IDLE Status: Open Resolution: None Bug Group: None Priority: 3 Summary: IDLE goto file/line (PR#352) Details: Jitterbug-Id: 352 Submitted-By: gpk@bell-labs.com Date: Fri, 9 Jun 2000 22:45:05 -0400 (EDT) Version: 1.6 CVS today OS: Solaris 2.6 When using IDLE's shell window Debug->Go to file/line, you have to be overly careful what you select. Specifically, if you select a region that contains a newline, IDLE won't be able to find a file and line number. For example, if you select v-- from there File "/export/h1/gpk/schoolweb.local/schoolweb/parse.py", line 199, in __str__ ^-- to there (i.e. 2 characters in, on the following line), you will get the following error message: "No special line: X the line you point to doesn't look like a file name followed by a line number." That is unfortunate, as it's really convenient to make a quick flick down from one line to the next, to select a complete line. By the way, the error box requires you to click "OK". That's a bug. It isn't OK. It's a crime against the King's English, committed by the minions of Bill Gates. You should not be following their lead. ==================================================================== Audit trail: Tue Jul 11 08:25:59 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110656&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:28:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:28:52 -0700 Subject: [Python-bugs-list] [Bug #110646] threads (PR#333) Message-ID: <200008231728.KAA06284@bush.i.sourceforge.net> Bug #110646, was updated on 2000-Jul-31 21:10 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: threads (PR#333) Details: Jitterbug-Id: 333 Submitted-By: savichev@physik.uni-freiburg.de Date: Sat, 20 May 2000 17:36:46 -0400 (EDT) Version: 1.6a2 OS: IRIX64 './configure --with-threads' won't pass test_signal during 'make test'. './regrtest.py -v test_signal' # adds on in Makefile fixes the problem. test_threads goes through and test_signal on the compiled python completes also. './regrtest.py -v' mode shows that script = """ ( set %(x)s sleep 2 kill -5 %(pid)d sleep 2 kill -2 %(pid)d sleep 2 kill -3 %(pid)d ) can't be fully completed. ==================================================================== Audit trail: Mon May 22 17:29:29 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110646&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:29:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:29:33 -0700 Subject: [Python-bugs-list] [Bug #110648] performance-problem decoding quoted-printable (PR#340) Message-ID: <200008231729.KAA06309@bush.i.sourceforge.net> Bug #110648, was updated on 2000-Jul-31 21:10 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 4 Summary: performance-problem decoding quoted-printable (PR#340) Details: Jitterbug-Id: 340 Submitted-By: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= Date: Fri, 26 May 2000 16:51:51 +0200 Version: None OS: None --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Problem on python 1.5.1 on linux 2.2.14aa6. Decoding quoted-printable files using mimetools.decode is really slow. The really strange thing is, that it appers to work a lot faster on smaller files! I put together a little test-program that reads blocks from a file, and decodes them individually. (The output will not be 100% correct. The point was just to test the performance). Results show the time it took to decode a 300k file with the diferent block-sizes: 1k: 6.28 s 3k: 6.59 s 10k: 8.57 s 30k: 30.45 s 100k: 127.82 s 300k: 221.67 s I looked in quopri.decode for clues about the problem, but could not find any. Is there something _very_ wrong with my reasoning, or is something wrong here? -- Ragnar Kjørstad --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="test.py" #!/usr/bin/python from mimetools import decode from StringIO import StringIO from sys import stdout, argv from string import atoi bsize=atoi(argv[1]) output=StringIO() f=open("mail-test") s=f.read(bsize) while s: input=StringIO(s) decode(input, output, 'quoted-printable') s=f.read(bsize) stdout.write('.') stdout.flush() stdout.write('done\n') --7JfCtLOvnd9MIVvH-- ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110648&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:31:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:31:20 -0700 Subject: [Python-bugs-list] [Bug #110675] Pth: test_fork1 fails, test_thread slow (PR#383) Message-ID: <200008231731.KAA06356@bush.i.sourceforge.net> Bug #110675, was updated on 2000-Jul-31 21:13 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: Pth: test_fork1 fails, test_thread slow (PR#383) Details: Jitterbug-Id: 383 Submitted-By: gregor@hoffleit.de Date: Tue, 4 Jul 2000 12:07:06 -0400 (EDT) Version: CVS version (06/04/00) OS: Debian potato (i386) When I use the current CVS version of Python to build on a Debian potato system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see below), and test_thread takes significantly longer to complete than when I build the same sources with native LinuxThreads. When running test.regrtest.main(), this happens: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import regrtest >>> regrtest.main() test_grammar test_opcodes ... test_extcall test_fcntl test_fork1 test test_fork1 crashed -- exceptions.AssertionError : Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 32, in f time.sleep(SHORTSLEEP) TypeError: illegal argument type for built-in operation Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' test_format test_gc ... When running test.test_fork1(), I get this: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_fork1 Traceback (most recent call last): File "", line 1, in ? File "./Lib/test/test_fork1.py", line 68, in ? main() File "./Lib/test/test_fork1.py", line 44, in main assert a == range(NUM_THREADS) AssertionError >>> test_thread takes very long to complete (5 min compared to 40 sec with LinuxThreads); when you look at the following log, you'll see that it tends to calls the threads serially !? clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_thread creating task 1 creating task 2 creating task 3 task 1 will run for 2.1 sec task 1 done creating task 4 task 2 will run for 3.2 sec creating task 5 task 2 done creating task task 3 will run for 9.1 6 sec task 3 done creating task 7 task 4 will run for 2.5 sec task 4 done creating task 8 task 5 will run for 0.9 sec task 5 done creating task 9 task 6 will run for 7.4 sec task 6 done creating task 10 waiting for all tasks to complete task 7 will run for 5.3 sec task 7 done task 8 will run for 2.6 sec task 8 done task 9 will run for 2.7 sec task 9 done task 10 will run for 0.9 sec task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 0 entering barrier 0 task 1 will run for 6.2 sec task 1 entering barrier 0 task 7 will run for 7.0 sec task 7 entering barrier 0 task 3 will run for 5.9 sec task 3 entering barrier 0 task 4 will run for 4.5 sec task 4 entering barrier 0 task 5 will run for 9.2 sec task 5 entering barrier 0 task 6 will run for 1.4 sec task 6 entering barrier 0 task 2 will run for 6.0 sec task 2 entering barrier 0 task 8 will run for 2.4 sec task 8 entering barrier 0 task 9 will run for 9.6 sec task 9 entering barrier 0 task 9 leaving barrier 0 task 0 leaving barrier 0 task task 1 leaving barrier 0 0 will run for 0.0 sec task 0 entering barrier 1 task 7 leaving barrier 0 task 9 will run for 0.8 sec task 9 entering barrier task 3 leaving barrier 0 1 task 1 task 4 leaving barrier 0 will run for 6.1 sec task 5 leaving barrier 0 task 1 entering barrier 1 task 6 leaving barrier 0 task 7 will run for 7.9 sec task 2 leaving barrier 0 task 7 entering barrier 1 task 3 task 8 leaving barrier 0 will run for 7.8 sec task 3 entering barrier 1 task 4 will run for 5.7 sec task 4 entering barrier 1 task 5 will run for 2.0 sec task 5 entering barrier 1 task 6 will run for 0.5 sec task 6 entering barrier 1 task 2 will run for 7.4 sec task 2 entering barrier 1 task 8 will run for 1.0 sec task 8 entering barrier 1 task 8 leaving barrier 1 task 7 leaving barrier 1 task 9 leaving barrier 1 task 1 leaving barrier 1 task 8 will run for 6.9 sec task 0 leaving barrier 1 task 8 entering barrier 2 task 0 will run for task 4 leaving barrier 1 0.0 sec task 7 will run for 4.3 sec task 0 entering barrier 2 task 3 leaving barrier 1 task 7 entering barrier 2 task 5 leaving barrier 1 task 6 leaving barrier 1 task 9 will run for 8.2 sec task task 2 leaving barrier 9 entering barrier 2 1 task 5 will run for 8.9 sec task 5 entering barrier 2 task 2 will run for 8.3 sec task 2 entering barrier 2 task 3 will run for 4.5 sec task 3 entering barrier 2 task 1 will run for 7.0 sec task 1 entering barrier 2 task 6 will run for 1.9 sec task 6 entering barrier 2 task 4 will run for 0.2 sec task 4 entering barrier 2 task 4 leaving barrier 2 task 8 leaving barrier 2 task 9 leaving barrier 2 task 7 leaving barrier 2 task 5 leaving barrier 2 task 0 leaving barrier 2 task 2 leaving barrier 2 task 3 leaving barrier 2 task 1 leaving barrier 2 task 6 leaving barrier 2 all tasks done while this is the log of the same test with Python 1.5.2 and LinuxThreads: clapton:3> python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from test import test_thread creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 8.9 sec task 2 will run for 8.3 sec task 3 will run for 9.1 sec task 5 will run for 6.0 sec task 4 will run for 7.5 sec task 6 will run for 4.7 sec task 7 will run for 4.2 sec task 8 will run for 7.0 sec task 9 will run for 8.7 sec task 10 will run for 9.5 sec task 7 done task 6 done task 5 done task 8 done task 4 done task 2 done task 9 done task 1 done task 3 done task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 1 will run for 2.8 sec task 0 entering barrier 0 task 2 will run for 5.3 sec task 3 will run for 9.2 sec task 5 will run for 8.0 sec task 4 will run for 8.9 sec task 6 will run for 5.0 sec task 7 will run for 1.3 sec task 8 will run for 5.6 sec task 9 will run for 4.7 sec task 7 entering barrier 0 task 1 entering barrier 0 task 9 entering barrier 0 task 6 entering barrier 0 task 2 entering barrier 0 task 8 entering barrier 0 task 5 entering barrier 0 task 4 entering barrier 0 task 3 entering barrier 0 task 3 leaving barrier 0 task 3 will run for 0.1 sec task 0 leaving barrier 0 task 0 will run for 0.0 sec task 7 leaving barrier 0 task 7 will run for 6.6 sec task 1 leaving barrier 0 task 1 will run for 1.0 sec task 9 leaving barrier 0 task 9 will run for 8.2 sec task 6 leaving barrier 0 task 6 will run for 1.0 sec task 2 leaving barrier 0 task 2 will run for 9.2 sec task 8 leaving barrier 0 task 8 will run for 4.4 sec task 5 leaving barrier 0 task 5 will run for 9.6 sec task 4 leaving barrier 0 task 4 will run for 1.7 sec task 0 entering barrier 1 task 3 entering barrier 1 task 1 entering barrier 1 task 6 entering barrier 1 task 4 entering barrier 1 task 8 entering barrier 1 task 7 entering barrier 1 task 9 entering barrier 1 task 2 entering barrier 1 task 5 entering barrier 1 task 5 leaving barrier 1 task 5 will run for 6.6 sec task 0 leaving barrier 1 task 0 will run for 0.0 sec task 3 leaving barrier 1 task 3 will run for 8.5 sec task 1 leaving barrier 1 task 1 will run for 0.1 sec task 6 leaving barrier 1 task 6 will run for 4.7 sec task 4 leaving barrier 1 task 4 will run for 4.7 sec task 8 leaving barrier 1 task 8 will run for 1.7 sec task 7 leaving barrier 1 task 7 will run for 1.8 sec task 9 leaving barrier 1 task 9 will run for 2.8 sec task 2 leaving barrier 1 task 2 will run for 3.3 sec task 0 entering barrier 2 task 1 entering barrier 2 task 8 entering barrier 2 task 7 entering barrier 2 task 9 entering barrier 2 task 2 entering barrier 2 task 6 entering barrier 2 task 4 entering barrier 2 task 5 entering barrier 2 task 3 entering barrier 2 task 3 leaving barrier 2 task 0 leaving barrier 2 task 1 leaving barrier 2 task 8 leaving barrier 2 task 7 leaving barrier 2 task 9 leaving barrier 2 task 2 leaving barrier 2 task 6 leaving barrier 2 task 4 leaving barrier 2 task 5 leaving barrier 2 all tasks done >>> ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 17:31 By: jhylton Comment: Another report of test_fork1 problems. Plan to resolve before 2.0b1. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110675&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:27:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:27:39 -0700 Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324) Message-ID: <200008231727.KAA06172@bush.i.sourceforge.net> Bug #110644, was updated on 2000-Jul-31 21:10 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in PyLong_FromLongLong (PR#324) Details: Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:35:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:35:02 -0700 Subject: [Python-bugs-list] [Bug #110683] compiling on WinNT (PR#403) Message-ID: <200008231735.KAA06520@bush.i.sourceforge.net> Bug #110683, was updated on 2000-Jul-31 21:14 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: None Priority: 6 Summary: compiling on WinNT (PR#403) Details: Jitterbug-Id: 403 Submitted-By: falk.lehmann@gmx.net Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT) Version: 1.6a2 OS: WinNT 4.0 I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. The compiler stops with some warnings and an error message: K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer is not a constant K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' : unreferenced local variable K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'char [4]' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047: 'initializing' : 'char *' differs in levels of indirection from 'unsigned int ' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl *)(struct _object *)' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047: 'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )' differs in levels of indirection from 'struct _object *(__cdecl *)(struct _object *,char *)' Thanks in advance for fixing (at least the error). Falk ==================================================================== Audit trail: Tue Jul 25 07:25:55 2000 guido changed notes Tue Jul 25 07:25:55 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 21:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 11:35:24 -0500 > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. Please try the current CVS tree (on its way to 2.0); we have no problems compiling this on VC 6.0. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Falk Lehmann Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 13:46:45 -0500 [magical fwd by GvR] Guido, sorry, but forgot to write, that I switched on the USE_SSL macro. And then the _socket module does not compile. Falk > > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. > > Please try the current CVS tree (on its way to 2.0); we have no > problems compiling this on VC 6.0. > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) > ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 14:00:20 -0500 > sorry, but forgot to write, that I switched on the USE_SSL macro. > And then the _socket module does not compile. It appears that the Python SSL code hasn't been ported to Windows. We'll add this to our TODO list, but it's low priority... Perhaps you could give it a shot yourself? See www.python.org/patches/ for how to contribute. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: Windows compile fails when using openSSL. ------------------------------------------------------- Date: 2000-Aug-23 17:35 By: jhylton Comment: This is a bug. Standard extensions modules should compile, even on obscure platforms like Windows NT. Need a Windows user with time to install OpenSSL to fix this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110683&group_id=5470 From noreply@sourceforge.net Wed Aug 23 18:36:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 10:36:29 -0700 Subject: [Python-bugs-list] [Bug #110675] Pth: test_fork1 fails, test_thread slow (PR#383) Message-ID: <200008231736.KAA06559@bush.i.sourceforge.net> Bug #110675, was updated on 2000-Jul-31 17:13 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: Pth: test_fork1 fails, test_thread slow (PR#383) Details: Jitterbug-Id: 383 Submitted-By: gregor@hoffleit.de Date: Tue, 4 Jul 2000 12:07:06 -0400 (EDT) Version: CVS version (06/04/00) OS: Debian potato (i386) When I use the current CVS version of Python to build on a Debian potato system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see below), and test_thread takes significantly longer to complete than when I build the same sources with native LinuxThreads. When running test.regrtest.main(), this happens: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import regrtest >>> regrtest.main() test_grammar test_opcodes ... test_extcall test_fcntl test_fork1 test test_fork1 crashed -- exceptions.AssertionError : Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 32, in f time.sleep(SHORTSLEEP) TypeError: illegal argument type for built-in operation Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' test_format test_gc ... When running test.test_fork1(), I get this: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_fork1 Traceback (most recent call last): File "", line 1, in ? File "./Lib/test/test_fork1.py", line 68, in ? main() File "./Lib/test/test_fork1.py", line 44, in main assert a == range(NUM_THREADS) AssertionError >>> test_thread takes very long to complete (5 min compared to 40 sec with LinuxThreads); when you look at the following log, you'll see that it tends to calls the threads serially !? clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_thread creating task 1 creating task 2 creating task 3 task 1 will run for 2.1 sec task 1 done creating task 4 task 2 will run for 3.2 sec creating task 5 task 2 done creating task task 3 will run for 9.1 6 sec task 3 done creating task 7 task 4 will run for 2.5 sec task 4 done creating task 8 task 5 will run for 0.9 sec task 5 done creating task 9 task 6 will run for 7.4 sec task 6 done creating task 10 waiting for all tasks to complete task 7 will run for 5.3 sec task 7 done task 8 will run for 2.6 sec task 8 done task 9 will run for 2.7 sec task 9 done task 10 will run for 0.9 sec task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 0 entering barrier 0 task 1 will run for 6.2 sec task 1 entering barrier 0 task 7 will run for 7.0 sec task 7 entering barrier 0 task 3 will run for 5.9 sec task 3 entering barrier 0 task 4 will run for 4.5 sec task 4 entering barrier 0 task 5 will run for 9.2 sec task 5 entering barrier 0 task 6 will run for 1.4 sec task 6 entering barrier 0 task 2 will run for 6.0 sec task 2 entering barrier 0 task 8 will run for 2.4 sec task 8 entering barrier 0 task 9 will run for 9.6 sec task 9 entering barrier 0 task 9 leaving barrier 0 task 0 leaving barrier 0 task task 1 leaving barrier 0 0 will run for 0.0 sec task 0 entering barrier 1 task 7 leaving barrier 0 task 9 will run for 0.8 sec task 9 entering barrier task 3 leaving barrier 0 1 task 1 task 4 leaving barrier 0 will run for 6.1 sec task 5 leaving barrier 0 task 1 entering barrier 1 task 6 leaving barrier 0 task 7 will run for 7.9 sec task 2 leaving barrier 0 task 7 entering barrier 1 task 3 task 8 leaving barrier 0 will run for 7.8 sec task 3 entering barrier 1 task 4 will run for 5.7 sec task 4 entering barrier 1 task 5 will run for 2.0 sec task 5 entering barrier 1 task 6 will run for 0.5 sec task 6 entering barrier 1 task 2 will run for 7.4 sec task 2 entering barrier 1 task 8 will run for 1.0 sec task 8 entering barrier 1 task 8 leaving barrier 1 task 7 leaving barrier 1 task 9 leaving barrier 1 task 1 leaving barrier 1 task 8 will run for 6.9 sec task 0 leaving barrier 1 task 8 entering barrier 2 task 0 will run for task 4 leaving barrier 1 0.0 sec task 7 will run for 4.3 sec task 0 entering barrier 2 task 3 leaving barrier 1 task 7 entering barrier 2 task 5 leaving barrier 1 task 6 leaving barrier 1 task 9 will run for 8.2 sec task task 2 leaving barrier 9 entering barrier 2 1 task 5 will run for 8.9 sec task 5 entering barrier 2 task 2 will run for 8.3 sec task 2 entering barrier 2 task 3 will run for 4.5 sec task 3 entering barrier 2 task 1 will run for 7.0 sec task 1 entering barrier 2 task 6 will run for 1.9 sec task 6 entering barrier 2 task 4 will run for 0.2 sec task 4 entering barrier 2 task 4 leaving barrier 2 task 8 leaving barrier 2 task 9 leaving barrier 2 task 7 leaving barrier 2 task 5 leaving barrier 2 task 0 leaving barrier 2 task 2 leaving barrier 2 task 3 leaving barrier 2 task 1 leaving barrier 2 task 6 leaving barrier 2 all tasks done while this is the log of the same test with Python 1.5.2 and LinuxThreads: clapton:3> python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from test import test_thread creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 8.9 sec task 2 will run for 8.3 sec task 3 will run for 9.1 sec task 5 will run for 6.0 sec task 4 will run for 7.5 sec task 6 will run for 4.7 sec task 7 will run for 4.2 sec task 8 will run for 7.0 sec task 9 will run for 8.7 sec task 10 will run for 9.5 sec task 7 done task 6 done task 5 done task 8 done task 4 done task 2 done task 9 done task 1 done task 3 done task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 1 will run for 2.8 sec task 0 entering barrier 0 task 2 will run for 5.3 sec task 3 will run for 9.2 sec task 5 will run for 8.0 sec task 4 will run for 8.9 sec task 6 will run for 5.0 sec task 7 will run for 1.3 sec task 8 will run for 5.6 sec task 9 will run for 4.7 sec task 7 entering barrier 0 task 1 entering barrier 0 task 9 entering barrier 0 task 6 entering barrier 0 task 2 entering barrier 0 task 8 entering barrier 0 task 5 entering barrier 0 task 4 entering barrier 0 task 3 entering barrier 0 task 3 leaving barrier 0 task 3 will run for 0.1 sec task 0 leaving barrier 0 task 0 will run for 0.0 sec task 7 leaving barrier 0 task 7 will run for 6.6 sec task 1 leaving barrier 0 task 1 will run for 1.0 sec task 9 leaving barrier 0 task 9 will run for 8.2 sec task 6 leaving barrier 0 task 6 will run for 1.0 sec task 2 leaving barrier 0 task 2 will run for 9.2 sec task 8 leaving barrier 0 task 8 will run for 4.4 sec task 5 leaving barrier 0 task 5 will run for 9.6 sec task 4 leaving barrier 0 task 4 will run for 1.7 sec task 0 entering barrier 1 task 3 entering barrier 1 task 1 entering barrier 1 task 6 entering barrier 1 task 4 entering barrier 1 task 8 entering barrier 1 task 7 entering barrier 1 task 9 entering barrier 1 task 2 entering barrier 1 task 5 entering barrier 1 task 5 leaving barrier 1 task 5 will run for 6.6 sec task 0 leaving barrier 1 task 0 will run for 0.0 sec task 3 leaving barrier 1 task 3 will run for 8.5 sec task 1 leaving barrier 1 task 1 will run for 0.1 sec task 6 leaving barrier 1 task 6 will run for 4.7 sec task 4 leaving barrier 1 task 4 will run for 4.7 sec task 8 leaving barrier 1 task 8 will run for 1.7 sec task 7 leaving barrier 1 task 7 will run for 1.8 sec task 9 leaving barrier 1 task 9 will run for 2.8 sec task 2 leaving barrier 1 task 2 will run for 3.3 sec task 0 entering barrier 2 task 1 entering barrier 2 task 8 entering barrier 2 task 7 entering barrier 2 task 9 entering barrier 2 task 2 entering barrier 2 task 6 entering barrier 2 task 4 entering barrier 2 task 5 entering barrier 2 task 3 entering barrier 2 task 3 leaving barrier 2 task 0 leaving barrier 2 task 1 leaving barrier 2 task 8 leaving barrier 2 task 7 leaving barrier 2 task 9 leaving barrier 2 task 2 leaving barrier 2 task 6 leaving barrier 2 task 4 leaving barrier 2 task 5 leaving barrier 2 all tasks done >>> ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 13:31 By: jhylton Comment: Another report of test_fork1 problems. Plan to resolve before 2.0b1. ------------------------------------------------------- Date: 2000-Aug-23 13:36 By: tim_one Comment: Jeremy, my chances of helping someone with a problem specific to "Debian potato system with GNU Pth 1.2.3" are nil. Assigned back to you since you seem to believe it's feasible . ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110675&group_id=5470 From noreply@sourceforge.net Wed Aug 23 19:11:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 11:11:06 -0700 Subject: [Python-bugs-list] [Bug #110696] strptime error (PR#149) Message-ID: <200008231811.LAA30279@delerium.i.sourceforge.net> Bug #110696, was updated on 2000-Jul-31 21:29 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Platform-specific Priority: 3 Summary: strptime error (PR#149) Details: Jitterbug-Id: 149 Submitted-By: python.org@netfinances.com Date: Sat, 4 Dec 1999 22:03:43 -0500 (EST) Version: 1.5.2 OS: RedHat Linux 6.0 strptime throws a ValueError exception when I feed it the hour 02, and a minute value equal to 40 or greater the following session illustrates: 1017:26:fred@firestorm:~/public_html >python Python 1.5.2 (#2, Dec 3 1999, 23:56:19) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from time import strptime >>> t = strptime('0230','%H%M') >>> t (1900, 1, 0, 23, 0, 0, 6, 1, 0) >>> t = strptime('0240','%H%M') Traceback (innermost last): File "", line 1, in ? ValueError: format mismatch >>> t = strptime('0140','%H%M') >>> t = strptime('0340','%H%M') >>> t = strptime('0345','%H%M') >>> t = strptime('0339','%H%M') >>> t = strptime('0240','%H%M') Traceback (innermost last): File "", line 1, in ? ValueError: format mismatch >>> t = strptime('0245','%H%M') Traceback (innermost last): File "", line 1, in ? ValueError: format mismatch >>> t = strptime('0250','%H%M') Traceback (innermost last): File "", line 1, in ? ValueError: format mismatch >>> t = strptime('0259','%H%M') Traceback (innermost last): File "", line 1, in ? ValueError: format mismatch >>> ==================================================================== Audit trail: Tue Dec 14 17:22:29 1999 guido sent reply 1 Tue Dec 14 17:22:48 1999 guido resent 149.reply.1 Tue Dec 14 17:24:30 1999 guido sent reply 2 Tue Dec 14 17:24:51 1999 guido changed notes Tue Dec 14 17:24:51 1999 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-01 21:03 By: none Comment: From: Guido van Rossum Subject: Re: strptime error (PR#149) Date: Tue Dec 14 17:22:29 1999 ------------------------------------------------------- Date: 2000-Aug-01 21:03 By: none Comment: From: Guido van Rossum Subject: Re: strptime error (PR#149) Date: Tue Dec 14 17:24:30 1999 > strptime throws a ValueError exception when I feed it the hour 02, and a minute > value > equal to 40 or greater the following session illustrates: Very strange. I can't reproduce this; I presume your platform's strptime() has a problem. --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 21:03 By: none Comment: Must be the strptime() implementation in his C library. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110696&group_id=5470 From noreply@sourceforge.net Wed Aug 23 19:16:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 11:16:16 -0700 Subject: [Python-bugs-list] [Bug #110691] popen2 and socket. (PR#53) Message-ID: <200008231816.LAA30498@delerium.i.sourceforge.net> Bug #110691, was updated on 2000-Jul-31 21:15 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: None Bug Group: Not a Bug Priority: 5 Summary: popen2 and socket. (PR#53) Details: Jitterbug-Id: 53 Submitted-By: tm@funcom.com Date: Mon, 16 Aug 1999 09:58:05 -0400 (EDT) Version: latest from CVS OS: Linux 2.2.10 libc5.3.12 When doing make test on the latest(as of 16 Aug 1999) python version, the popen2 and socket tests fail. output from test_popen2: testing popen2... Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 84, in _test r, w = popen2('cat') File "../../Lib/popen2.py", line 73, in popen2 inst = Popen3(cmd, 0, bufsize) File "../../Lib/popen2.py", line 24, in __init__ os.close(0) OSError: [Errno 9] Bad file number Traceback (innermost last): File "test_popen2.py", line 16, in ? main() File "test_popen2.py", line 14, in main popen2._test() File "../../Lib/popen2.py", line 87, in _test assert r.read() == teststr AssertionError output from test_socket: socket.error Traceback (innermost last): File "test_socket.py", line 71, in ? ip = socket.gethostbyname(hostname) socket.error: host not found ==================================================================== Audit trail: Mon Aug 16 10:13:57 1999 guido changed notes Mon Aug 16 10:13:57 1999 guido moved from incoming to notabug Mon Aug 16 10:15:22 1999 guido sent reply 1 Mon Aug 16 13:33:03 1999 guido changed notes Mon Aug 16 14:24:25 1999 guido changed notes Mon Aug 16 14:24:25 1999 guido moved from notabug to open Wed Jul 26 18:27:01 2000 guido resent 53.reply.1 Follow-Ups: Date: 2000-Aug-01 21:02 By: none Comment: From: Guido van Rossum Subject: Re: popen2 and socket. (PR#53) Date: Mon Aug 16 10:15:22 1999 This is not a Python bug. Your network environment has not been set up properly. Don't worry unless you want to use sockets (in that case you have to figure out how to set up your Linux networking; Python will automatically follow). ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Terje Malmedal Subject: Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 16:41:58 +0200 [Guido van Rossum] > This is not a Python bug. > Your network environment has not been set up properly. Yes it is. The machine is connected to the internet. Everything else, including Apache and Perl are able to use the network. I forgot to mention that Python 1.5.1 works with no problems. > Don't worry unless you want to use sockets > (in that case you have to figure out how to set > up your Linux networking; Python will automatically follow). -- - Terje tm@funcom.com ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 11:36:25 -0400 > [Guido van Rossum] > > This is not a Python bug. > > Your network environment has not been set up properly. > > Yes it is. The machine is connected to the internet. Everything else, > including Apache and Perl are able to use the network. > > I forgot to mention that Python 1.5.1 works with no problems. The specific problem is with the DNS. The failing line in test_socket.py checks that the DNS lookup for the result of gethostname() succeeds. In your case, it fails. There are tons of possible reasons why it would fail: perhaps gethostname() returns a host without a domain, or perhaps your hostname isn't registered in your DNS. You may be able to fix it by editing /etc/hosts. If (as you say) the rest of the network works fine, you don't have to worry about the two failing tests. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Terje Malmedal Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 19:17:59 +0200 [Guido van Rossum] >> [Guido van Rossum] >> > This is not a Python bug. >> > Your network environment has not been set up properly. >> >> Yes it is. The machine is connected to the internet. Everything else, >> including Apache and Perl are able to use the network. >> >> I forgot to mention that Python 1.5.1 works with no problems. > The specific problem is with the DNS. The failing line in > test_socket.py checks that the DNS lookup for the result of > gethostname() succeeds. In your case, it fails. There are tons of > possible reasons why it would fail: perhaps gethostname() returns a > host without a domain, or perhaps your hostname isn't registered in > your DNS. You may be able to fix it by editing /etc/hosts. Something else is going on, I built python 1.5.1 and 1.5.2 on the exact same machine with exact same configure statements: Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import socket >>> socket.gethostbyname("cnn.com") Traceback (innermost last): File "", line 1, in ? socket.error: host not found >>> Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import socket >>> socket.gethostbyname("cnn.com") '207.25.71.12' >>> gethostbyname("localhost") gives the same result, works in 1.5.1, but not in 1.5.2. -- - Terje tm@funcom.com ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 13:21:56 -0400 > Something else is going on, I built python 1.5.1 and 1.5.2 on the > exact same machine with exact same configure statements: > > Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import socket > >>> socket.gethostbyname("cnn.com") > Traceback (innermost last): > File "", line 1, in ? > socket.error: host not found > >>> > > Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import socket > >>> socket.gethostbyname("cnn.com") > '207.25.71.12' > >>> > > gethostbyname("localhost") gives the same result, works in 1.5.1, but > not in 1.5.2. Hm, all this works fine on any machine I can test it on, and I haven't heard this problem reported before. So I speculate that somehow your Python 1.5.2 build is broken. I don't know how you help you any further; perhaps you can try the newsgroup -- or just download Oliver Andrich's RPMs... --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Terje Malmedal Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 20:17:39 +0200 [Guido van Rossum] >> Something else is going on, I built python 1.5.1 and 1.5.2 on the >> exact same machine with exact same configure statements: >> >> Python 1.5.2 (#9, Aug 16 1999, 19:08:25) [GCC egcs-2.91.66 19990314 (egcs-1.1.2 on linux2 >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> import socket >> >>> socket.gethostbyname("cnn.com") >> Traceback (innermost last): >> File "", line 1, in ? >> socket.error: host not found >> >>> >> >> Python 1.5.1 (#4, Aug 16 1999, 18:15:50) [GCC egcs-2.91.66 19990314 (e on linux2 >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> import socket >> >>> socket.gethostbyname("cnn.com") >> '207.25.71.12' >> >>> >> >> gethostbyname("localhost") gives the same result, works in 1.5.1, but >> not in 1.5.2. > Hm, all this works fine on any machine I can test it on, and I haven't > heard this problem reported before. So I speculate that somehow your > Python 1.5.2 build is broken. I don't know how you help you any > further; perhaps you can try the newsgroup -- or just download Oliver > Andrich's RPMs... I finally found it, in socketmodule.c O replaced this: #elif defined(linux) #define HAVE_GETHOSTBYNAME_R_6_ARG #else with this: #elif defined(linux) #define HAVE_GETHOSTBYNAME_R_5_ARG #else And everything worked. Strange that nobody else has noticed this, maybe it's a libc versus glibc thing or something. Anyway, thanks for your time. -- - Terje tm@funcom.com ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Re: popen2 and socket. (PR#53) Date: Mon, 16 Aug 1999 14:22:49 -0400 > I finally found it, in socketmodule.c O replaced this: > > #elif defined(linux) > #define HAVE_GETHOSTBYNAME_R_6_ARG > #else > > with this: > > #elif defined(linux) > #define HAVE_GETHOSTBYNAME_R_5_ARG > #else > > And everything worked. Strange that nobody else has noticed this, > maybe it's a libc versus glibc thing or something. > > Anyway, thanks for your time. Ah, thanks! As you say, this is probably dependent on your libc version. A better solution should be found, really... I'll mark the bug report as "open". --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 21:02 By: none Comment: His Linux has a 5-arg gethostbyname() instead of a 6-arg gethostbyname(). This should really be determined in a more foolproof way in the configure script! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110691&group_id=5470 From noreply@sourceforge.net Wed Aug 23 19:20:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 11:20:23 -0700 Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324) Message-ID: <200008231820.LAA30678@delerium.i.sourceforge.net> Bug #110644, was updated on 2000-Jul-31 17:10 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in PyLong_FromLongLong (PR#324) Details: Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 14:20 By: tim_one Comment: Reassigned from Trent to me -- Python had the same bug in its "regular int" code for years, and I fixed it there, so I should fix it here too. 'Tis tricky to get right. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470 From noreply@sourceforge.net Wed Aug 23 19:57:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 11:57:01 -0700 Subject: [Python-bugs-list] [Bug #112573] test_re crashes when compiled with -DPy_DEBUG Message-ID: <200008231857.LAA32143@delerium.i.sourceforge.net> Bug #112573, was updated on 2000-Aug-23 18:57 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: test_re crashes when compiled with -DPy_DEBUG Details: ./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 Test engine limitations maximum recursion limit exceeded FATAL: node type 304, required 310 Aborted (core dumped) bitdiddle:~/src/python/dist/src/build-Py_DEBUG> For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112573&group_id=5470 From noreply@sourceforge.net Wed Aug 23 23:08:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 15:08:42 -0700 Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324) Message-ID: <200008232208.PAA06789@delerium.i.sourceforge.net> Bug #110644, was updated on 2000-Jul-31 21:10 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in PyLong_FromLongLong (PR#324) Details: Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 18:20 By: tim_one Comment: Reassigned from Trent to me -- Python had the same bug in its "regular int" code for years, and I fixed it there, so I should fix it here too. 'Tis tricky to get right. ------------------------------------------------------- Date: 2000-Aug-23 22:08 By: tmick Comment: Tim, Sorry to have left this siting here. I did not know that it was assigned to me. The code is now: if ((LONG_LONG)LONG_MIN <= ival && ival <= (LONG_LONG)LONG_MAX) { return PyLong_FromLong( (long)ival ); } else if (0 <= ival && ival <= (unsigned LONG_LONG)ULONG_MAX) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { which means that the bug is fixed n'est ce pas? I remember discussing this way back (though "way back" for me is like last week for you). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470 From noreply@sourceforge.net Thu Aug 24 01:27:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 17:27:51 -0700 Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324) Message-ID: <200008240027.RAA11798@delerium.i.sourceforge.net> Bug #110644, was updated on 2000-Jul-31 17:10 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in PyLong_FromLongLong (PR#324) Details: Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 14:20 By: tim_one Comment: Reassigned from Trent to me -- Python had the same bug in its "regular int" code for years, and I fixed it there, so I should fix it here too. 'Tis tricky to get right. ------------------------------------------------------- Date: 2000-Aug-23 18:08 By: tmick Comment: Tim, Sorry to have left this siting here. I did not know that it was assigned to me. The code is now: if ((LONG_LONG)LONG_MIN <= ival && ival <= (LONG_LONG)LONG_MAX) { return PyLong_FromLong( (long)ival ); } else if (0 <= ival && ival <= (unsigned LONG_LONG)ULONG_MAX) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { which means that the bug is fixed n'est ce pas? I remember discussing this way back (though "way back" for me is like last week for you). ------------------------------------------------------- Date: 2000-Aug-23 20:27 By: tim_one Comment: What do you mean you didn't know it was assigned to you? It was assigned to you for an entire 7 minutes before I reassigned it to me ! So I assigned it back to you. You're indeed right about the fix -- I had hallucinated this into something deeper than it was. Better for you to fix it since you can actually test it! Thanks, Trent. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470 From noreply@sourceforge.net Thu Aug 24 02:50:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 18:50:32 -0700 Subject: [Python-bugs-list] [Bug #110607] Telnet close (PR#181) Message-ID: <200008240150.SAA14421@delerium.i.sourceforge.net> Bug #110607, was updated on 2000-Jul-31 17:05 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Telnet close (PR#181) Details: Jitterbug-Id: 181 Submitted-By: cha@tandberg.no Date: Wed, 12 Jan 2000 09:49:29 -0500 (EST) Version: 1.5.2 OS: Windows NT4.0 The telnet.close() object does not close the telnet session. Session will only be closed after a timeout on the remote side. ==================================================================== Audit trail: Wed Jan 12 18:29:38 2000 guido changed notes Wed Jan 12 18:29:38 2000 guido changed notification Wed Jan 12 18:29:38 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 21:50 By: montanaro Comment: Replied to the submitter asking for a short script that fails. I don't run Windows so I may not be able to track this down. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110607&group_id=5470 From noreply@sourceforge.net Thu Aug 24 05:22:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 21:22:31 -0700 Subject: [Python-bugs-list] [Bug #110832] urljoin() bug with odd no of '..' (PR#194) Message-ID: <200008240422.VAA19449@delerium.i.sourceforge.net> Bug #110832, was updated on 2000-Aug-01 17:13 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: Invalid Bug Group: Not a Bug Priority: 6 Summary: urljoin() bug with odd no of '..' (PR#194) Details: Jitterbug-Id: 194 Submitted-By: DrMalte@ddd.de Date: Sun, 30 Jan 2000 19:40:45 -0500 (EST) Version: 1.5.2 and 1.4 OS: Linux While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing . The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) ==================================================================== Audit trail: Mon Feb 07 12:35:35 2000 guido changed notes Mon Feb 07 12:35:35 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 17:13 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Date: Mon, 31 Jan 2000 12:28:55 -0500 Thanks for your bug report and fix. I agree with your diagnosis. Would you please be so kind as to resend your patch with the legal disclaimer from http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 17:13 By: none Comment: Patch being considered. ------------------------------------------------------- Date: 2000-Aug-13 04:36 By: moshez Comment: OK, Jeremy -- this one is yours. Either notabug it, or check in the relevant patch (101064 -- assigned to you) ------------------------------------------------------- Date: 2000-Aug-24 00:22 By: fdrake Comment: RFC 1808 gives examples of this form in section 5.2, "Abnormal Examples," and gives the current behavior as the desired treatment, stating that all parsers (urljoin() counts given the RFC's terminology) should treat the abnormal examples consistently. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110832&group_id=5470 From noreply@sourceforge.net Thu Aug 24 05:23:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 23 Aug 2000 21:23:23 -0700 Subject: [Python-bugs-list] [Bug #110832] urljoin() bug with odd no of '..' (PR#194) Message-ID: <200008240423.VAA19494@delerium.i.sourceforge.net> Bug #110832, was updated on 2000-Aug-01 17:13 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 6 Summary: urljoin() bug with odd no of '..' (PR#194) Details: Jitterbug-Id: 194 Submitted-By: DrMalte@ddd.de Date: Sun, 30 Jan 2000 19:40:45 -0500 (EST) Version: 1.5.2 and 1.4 OS: Linux While playing with linbot I noticed some failed requests to 'http://xxx.xxx.xx/../img/xxx.gif' for a document in the root directory containing . The Reason is in urlparse.urljoin() urljoin() fails to remove an odd number of '../' from the path. Demonstration: from urlparse import urljoin print urljoin( 'http://127.0.0.1/', '../imgs/logo.gif' ) # gives 'http://127.0.0.1/../imgs/logo.gif' # should give 'http://127.0.0.1/imgs/logo.gif' print urljoin( 'http://127.0.0.1/', '../../imgs/logo.gif' ) # gives 'http://127.0.0.1/imgs/logo.gif' # works # '../../imgs/logo.gif' gives 'http://127.0.0.1/../imgs/logo.gif' and so on The patch for 1.5.2 ( I'm not sure if it works generally, but tests with linbot looked good) *** /usr/local/lib/python1.5/urlparse.py Sat Jun 26 19:11:59 1999 --- urlparse.py Mon Jan 31 01:31:45 2000 *************** *** 170,175 **** --- 170,180 ---- segments[-1] = '' elif len(segments) >= 2 and segments[-1] == '..': segments[-2:] = [''] + + if segments[0] == '': + while segments[1] == '..': # remove all leading '..' + del segments[1] + return urlunparse((scheme, netloc, joinfields(segments, '/'), params, query, fragment)) ==================================================================== Audit trail: Mon Feb 07 12:35:35 2000 guido changed notes Mon Feb 07 12:35:35 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 17:13 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] urljoin() bug with odd no of '..' (PR#194) Date: Mon, 31 Jan 2000 12:28:55 -0500 Thanks for your bug report and fix. I agree with your diagnosis. Would you please be so kind as to resend your patch with the legal disclaimer from http://www.python.org/1.5/bugrelease.html --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 17:13 By: none Comment: Patch being considered. ------------------------------------------------------- Date: 2000-Aug-13 04:36 By: moshez Comment: OK, Jeremy -- this one is yours. Either notabug it, or check in the relevant patch (101064 -- assigned to you) ------------------------------------------------------- Date: 2000-Aug-24 00:22 By: fdrake Comment: RFC 1808 gives examples of this form in section 5.2, "Abnormal Examples," and gives the current behavior as the desired treatment, stating that all parsers (urljoin() counts given the RFC's terminology) should treat the abnormal examples consistently. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110832&group_id=5470 From noreply@sourceforge.net Thu Aug 24 12:50:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 04:50:38 -0700 Subject: [Python-bugs-list] [Bug #112628] many extensions (wrongly?) use Py_FatalError Message-ID: <200008241150.EAA11811@bush.i.sourceforge.net> Bug #112628, was updated on 2000-Aug-24 11:50 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: many extensions (wrongly?) use Py_FatalError Details: Many of the modules in the current CVS tree are handling errors in a manner which I find unpythonic. A typical example is pyexpat.c which at the end of initpyexpat does /* Check for errors */ if (PyErr_Occurred()) Py_FatalError("can't initialize module pyexpat"); the xml-sig group might regard this as a tragedy, but I might wish to continue and use another parser. The correct behaviour for this sort of error ought IMHO to be to raise an ImportError clean up any privately allocated resources and return. c sources which raise fatal errors _cursesmodule.c: _localemodule.c: _tkinter.c: almodule.c: cdmodule.c: errnomodule.c: fcntlmodule.c: fpectlmodule.c: linuxaudiodev.c: main.c: mathmodule.c: mpzmodule.c: parsermodule.c: pcremodule.c: posixmodule.c: puremodule.c: pyexpat.c: shamodule.c: stropmodule.c: syslogmodule.c: timemodule.c: timingmodule.c: For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112628&group_id=5470 From guenter@ubka.uni-karlsruhe.de Thu Aug 24 13:43:29 2000 From: guenter@ubka.uni-karlsruhe.de (guenter@ubka.uni-karlsruhe.de) Date: Thu, 24 Aug 2000 08:43:29 -0400 (EDT) Subject: [Python-bugs-list] The Python 1.5.2 cgi module chews up memory (PR#435) Message-ID: <20000824124329.E39F01CE3D@dinsdale.python.org> Hello, I have a problem with one of my Python CGIs and am not sure what to do about this. I have found a related message in the bug reporting system but do not know how to use this system to enter my problem so I will describe it in this mail. URL of related problem: http://www.python.org/python-bugs/notabug?id=396;expression=FieldStorage;user=guest My application grows to about twice the size of an uploaded file when executing the statement self.form = cgi.FieldStorage() I have taken great care not to use form['something'].value to make it possible to upload large files but this does not help because the problem occurs much earlier. Referring to the related problem mentioned above: I do not use Zope, only the CGI module in the Python distribution. The file I upload does contain a lot of new line characters. The mime encoded version of the file should also contain new line characters. I have not (yet) checked where in cgi.py the memory is used and what it is used for. I have been logging this with the following code on Linux: def log(self, info): # get the process size from the proc fs - will work only on linux: pid = os.getpid() pstat = open(os.path.join('/proc', '%s' % pid, 'stat')).read() size = string.atoi(string.split(pstat)[22]) / 1024 # append some information to the log file: where = string.rstrip(traceback.format_stack()[-2]) where = string.split(where, '\n')[:1] self.logfile.write('pid=%s, size=%s, At %s: %s\n' % (pid, size, where, info)) self.logfile.flush() only to realize the problem must be in cgi.py. Is this a known problem and is there a fix for it? Can I do anything to get this fixed in future distributions of Python? Thanks in advance for Your help. -- Guenter Radestock, Universitaetsbibliothek Karlsruhe guenter@ubka.uni-karlsruhe.de http://www.ubka.uni-karlsruhe.de/~guenter From noreply@sourceforge.net Thu Aug 24 13:54:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 05:54:10 -0700 Subject: [Python-bugs-list] [Bug #112628] many extensions (wrongly?) use Py_FatalError Message-ID: <200008241254.FAA04132@delerium.i.sourceforge.net> Bug #112628, was updated on 2000-Aug-24 11:50 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: many extensions (wrongly?) use Py_FatalError Details: Many of the modules in the current CVS tree are handling errors in a manner which I find unpythonic. A typical example is pyexpat.c which at the end of initpyexpat does /* Check for errors */ if (PyErr_Occurred()) Py_FatalError("can't initialize module pyexpat"); the xml-sig group might regard this as a tragedy, but I might wish to continue and use another parser. The correct behaviour for this sort of error ought IMHO to be to raise an ImportError clean up any privately allocated resources and return. c sources which raise fatal errors _cursesmodule.c: _localemodule.c: _tkinter.c: almodule.c: cdmodule.c: errnomodule.c: fcntlmodule.c: fpectlmodule.c: linuxaudiodev.c: main.c: mathmodule.c: mpzmodule.c: parsermodule.c: pcremodule.c: posixmodule.c: puremodule.c: pyexpat.c: shamodule.c: stropmodule.c: syslogmodule.c: timemodule.c: timingmodule.c: Follow-Ups: Date: 2000-Aug-24 12:54 By: gvanrossum Comment: He's right! The proper solution is if (PyErr_Occurred()) return; since the module initialization code explicitly checks for errors raised by the module's init function. Assigned to Jeremy for pronouncement or delegation. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112628&group_id=5470 From noreply@sourceforge.net Thu Aug 24 14:01:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 06:01:29 -0700 Subject: [Python-bugs-list] [Bug #112634] urllib doesn't look at self.version as documented Message-ID: <200008241301.GAA04375@delerium.i.sourceforge.net> Bug #112634, was updated on 2000-Aug-24 13:01 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urllib doesn't look at self.version as documented Details: [The following came from a .cz domain so I'm posting for him. GvR] (I believe this is actually easily fixable in the code to make the docs correct. GvR) From: Dundáèek Jan To: guido@python.org Date: Thu, 24 Aug 2000 13:06:15 +0200 There is an example on urllib in Python Library Reference Release 1.5.2 (p. 211, A4 pdf): -- For example, applications may want to specify a different user-agent header than URLopener defines. This can be accomplished with the following code: class AppURLopener(urllib.FancyURLopener): def __init__(self, *args): apply(urllib.FancyURLopener.__init__, (self,) + args) self.version = "App/1.7" urllib._urlopener = AppURLopener -- I was trying it, but it doesn't work - may be that error is in: self.version = "App/1.7" When I looked at urllib.py, I found only: server_version = "Python-urllib/%s" % __version__ self.addheaders = [('User-agent', server_version)] in URLopener.__init__. And when I redefined __init__ in such a way, it works. Thanks for Python Jan ------------------------------------------------ Jan Dundacek PVT a.s. Jan.Dundacek@pvt.cz Veveri 102 +420-5-41558-347 659 10 Brno Czech republic ------------------------------------------------ For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112634&group_id=5470 From noreply@sourceforge.net Thu Aug 24 14:03:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 06:03:14 -0700 Subject: [Python-bugs-list] [Bug #112634] urllib doesn't look at self.version as documented Message-ID: <200008241303.GAA04492@delerium.i.sourceforge.net> Bug #112634, was updated on 2000-Aug-24 13:01 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urllib doesn't look at self.version as documented Details: [The following came from a .cz domain so I'm posting for him. GvR] (I believe this is actually easily fixable in the code to make the docs correct. GvR) From: Dundáèek Jan To: guido@python.org Date: Thu, 24 Aug 2000 13:06:15 +0200 There is an example on urllib in Python Library Reference Release 1.5.2 (p. 211, A4 pdf): -- For example, applications may want to specify a different user-agent header than URLopener defines. This can be accomplished with the following code: class AppURLopener(urllib.FancyURLopener): def __init__(self, *args): apply(urllib.FancyURLopener.__init__, (self,) + args) self.version = "App/1.7" urllib._urlopener = AppURLopener -- I was trying it, but it doesn't work - may be that error is in: self.version = "App/1.7" When I looked at urllib.py, I found only: server_version = "Python-urllib/%s" % __version__ self.addheaders = [('User-agent', server_version)] in URLopener.__init__. And when I redefined __init__ in such a way, it works. Thanks for Python Jan ------------------------------------------------ Jan Dundacek PVT a.s. Jan.Dundacek@pvt.cz Veveri 102 +420-5-41558-347 659 10 Brno Czech republic ------------------------------------------------ For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112634&group_id=5470 From noreply@sourceforge.net Thu Aug 24 14:18:51 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 06:18:51 -0700 Subject: [Python-bugs-list] [Bug #111802] anydbm cannot verify shelve database type Message-ID: <200008241318.GAA05044@delerium.i.sourceforge.net> Bug #111802, was updated on 2000-Aug-13 17:05 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Trash Priority: 5 Summary: anydbm cannot verify shelve database type Details: When opening an existing "shelve" database file. An exception is raised from anydbm saying "the database type could not be determined". Follow-Ups: Date: 2000-Aug-24 13:18 By: moshez Comment: This sounds like the bug I fixed in whichdb (it couldn't recognize Python's dumbdbm). Assigned to me so I can deal with it (i.e., verify that it does happen on old Python, and doesn't happen to the CVS version). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111802&group_id=5470 From noreply@sourceforge.net Thu Aug 24 15:54:43 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 07:54:43 -0700 Subject: [Python-bugs-list] [Bug #112628] many extensions (wrongly?) use Py_FatalError Message-ID: <200008241454.HAA08618@delerium.i.sourceforge.net> Bug #112628, was updated on 2000-Aug-24 07:50 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: many extensions (wrongly?) use Py_FatalError Details: Many of the modules in the current CVS tree are handling errors in a manner which I find unpythonic. A typical example is pyexpat.c which at the end of initpyexpat does /* Check for errors */ if (PyErr_Occurred()) Py_FatalError("can't initialize module pyexpat"); the xml-sig group might regard this as a tragedy, but I might wish to continue and use another parser. The correct behaviour for this sort of error ought IMHO to be to raise an ImportError clean up any privately allocated resources and return. c sources which raise fatal errors _cursesmodule.c: _localemodule.c: _tkinter.c: almodule.c: cdmodule.c: errnomodule.c: fcntlmodule.c: fpectlmodule.c: linuxaudiodev.c: main.c: mathmodule.c: mpzmodule.c: parsermodule.c: pcremodule.c: posixmodule.c: puremodule.c: pyexpat.c: shamodule.c: stropmodule.c: syslogmodule.c: timemodule.c: timingmodule.c: Follow-Ups: Date: 2000-Aug-24 08:54 By: gvanrossum Comment: He's right! The proper solution is if (PyErr_Occurred()) return; since the module initialization code explicitly checks for errors raised by the module's init function. Assigned to Jeremy for pronouncement or delegation. ------------------------------------------------------- Date: 2000-Aug-24 10:54 By: bwarsaw Comment: In that case, the PyErr_Occurred() call is /usually/ not necessary, since it's done as the last thing in the init() function and would just return anyway. So given Guido's pronouncement, most of those checks can just be removed. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112628&group_id=5470 From noreply@sourceforge.net Thu Aug 24 16:07:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 08:07:42 -0700 Subject: [Python-bugs-list] [Bug #110633] urlparse (PR#286) Message-ID: <200008241507.IAA09035@delerium.i.sourceforge.net> Bug #110633, was updated on 2000-Jul-31 17:09 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Summary: urlparse (PR#286) Details: Jitterbug-Id: 286 Submitted-By: alex@shop.com Date: Mon, 10 Apr 2000 16:40:57 -0400 (EDT) Version: >=1.5 OS: win32 linux urlparse requires that the url contain a "/" so that urlparse("http://foo.com?q=a#blah") results in ("http","foo.com?q=a#blah",....) urlparse should not require slashes in urls that have fragments or query strings. ==================================================================== Audit trail: Tue Jul 11 08:29:15 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-16 21:54 By: fdrake Comment: Assigned to me so I can deal with urlparse all at once. ------------------------------------------------------- Date: 2000-Aug-24 11:07 By: fdrake Comment: RFC 1738, section 3.3, discusses the syntax for HTTP URLs. It implies that the "/" between the is required if either the path of searchpart of the URL is provided, but is not completely clear. I don't see anything relevant in RFC 1945 (HTTP 1.0), but RFC 2616 (HTTP 1.1), section 3.2.2 clearly indicates that the search part should only exist as a part of the path component, which is required to include the leading "/". There is some confusion as to how this should relate to parsing of relative URLs (RFC 1808). This bug can be re-opened if there's evidence urlparse is actually wrong or inconsistent with other URL parsers. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110633&group_id=5470 From guido@beopen.com Thu Aug 24 18:05:59 2000 From: guido@beopen.com (Guido van Rossum) Date: Thu, 24 Aug 2000 12:05:59 -0500 Subject: [Python-bugs-list] The Python 1.5.2 cgi module chews up memory (PR#435) In-Reply-To: Your message of "Thu, 24 Aug 2000 08:43:29 -0400." <20000824124329.E39F01CE3D@dinsdale.python.org> References: <20000824124329.E39F01CE3D@dinsdale.python.org> Message-ID: <200008241705.MAA02655@cj20424-a.reston1.va.home.com> We no longer use Jitterbug for our bugs database. Please use the SourceForge bugs manager to report a bug: http://sourceforge.net/bugs/?group_id=5470 If you need help figuring what's going on, please use comp.lang.python. This particular problem looks like it's probably not a bug, so I suggest you get a quicker response there. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/) From noreply@sourceforge.net Thu Aug 24 17:20:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 09:20:53 -0700 Subject: [Python-bugs-list] [Bug #112634] urllib doesn't look at self.version as documented Message-ID: <200008241620.JAA11892@delerium.i.sourceforge.net> Bug #112634, was updated on 2000-Aug-24 13:01 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: urllib doesn't look at self.version as documented Details: [The following came from a .cz domain so I'm posting for him. GvR] (I believe this is actually easily fixable in the code to make the docs correct. GvR) From: Dundáèek Jan To: guido@python.org Date: Thu, 24 Aug 2000 13:06:15 +0200 There is an example on urllib in Python Library Reference Release 1.5.2 (p. 211, A4 pdf): -- For example, applications may want to specify a different user-agent header than URLopener defines. This can be accomplished with the following code: class AppURLopener(urllib.FancyURLopener): def __init__(self, *args): apply(urllib.FancyURLopener.__init__, (self,) + args) self.version = "App/1.7" urllib._urlopener = AppURLopener -- I was trying it, but it doesn't work - may be that error is in: self.version = "App/1.7" When I looked at urllib.py, I found only: server_version = "Python-urllib/%s" % __version__ self.addheaders = [('User-agent', server_version)] in URLopener.__init__. And when I redefined __init__ in such a way, it works. Thanks for Python Jan ------------------------------------------------ Jan Dundacek PVT a.s. Jan.Dundacek@pvt.cz Veveri 102 +420-5-41558-347 659 10 Brno Czech republic ------------------------------------------------ Follow-Ups: Date: 2000-Aug-24 16:20 By: gvanrossum Comment: Fixed urllib.py and the example -- this can only be made to work if one assigns to self.version *before* calling the base class __init__(). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112634&group_id=5470 From noreply@sourceforge.net Thu Aug 24 17:56:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 09:56:52 -0700 Subject: [Python-bugs-list] [Bug #112558] dictionary lookup does not check exceptions Message-ID: <200008241656.JAA23186@bush.i.sourceforge.net> Bug #112558, was updated on 2000-Aug-23 10:24 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 9 Summary: dictionary lookup does not check exceptions Details: class BadDictKey: def __hash__(self): return hash(self.__class__) def __cmp__(self, other): if isinstance(other, self.__class__): print "raising error" raise RuntimeError, "gotcha" return other The dict lookup code does not check for hash or cmp functions raising an exception. This can lead to a variety of bogus behavior; e.g. the uncaught exception is noticed and raised for the next line. >>> d = {} >>> x1 = BadDictKey() >>> x2 = BadDictKey() >>> d[x1] = 1 >>> d[x2] = 2 raising error >>> print d.keys() Traceback (most recent call last): File "/tmp/dicterr.py", line 8, in __cmp__ raise RuntimeError, "gotcha" RuntimeError: gotcha Follow-Ups: Date: 2000-Aug-24 12:56 By: fdrake Comment: See patch #101277 for a proposed fix & discussion. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112558&group_id=5470 From bwarsaw@beopen.com Thu Aug 24 19:20:24 2000 From: bwarsaw@beopen.com (bwarsaw@beopen.com) Date: Thu, 24 Aug 2000 14:20:24 -0400 (EDT) Subject: [Python-bugs-list] testing -- ignore (PR#436) Message-ID: <20000824182024.ED9841D268@dinsdale.python.org> From barry@wooz.org Thu Aug 24 19:25:17 2000 From: barry@wooz.org (barry@wooz.org) Date: Thu, 24 Aug 2000 14:25:17 -0400 (EDT) Subject: [Python-bugs-list] testing -- ignore (PR#437) Message-ID: <20000824182517.2CC861D268@dinsdale.python.org> From naris@ensim.com Thu Aug 24 19:47:37 2000 From: naris@ensim.com (naris@ensim.com) Date: Thu, 24 Aug 2000 14:47:37 -0400 (EDT) Subject: [Python-bugs-list] Re: The Python 1.5.2 cgi module chews up memory (PR#438) Message-ID: <20000824184737.1F7371D2BB@dinsdale.python.org> our problem was in cgi.py of the zope distribution, which is different from the py distribution. the bloat was in the code that handled the multipart file upload. you may want to step through or put debugging output into the parse_multipart function. On Thu, 24 Aug 2000, Guenter Radestock wrote: > Hello, > > I have a problem with one of my Python CGIs and am not sure what to do > about this. I have found a related message in the bug reporting system > but do not know how to use this system to enter my problem so I will > describe it in this mail. > > URL of related problem: > http://www.python.org/python-bugs/notabug?id=396;expression=FieldStorage;user=guest > > My application grows to about twice the size of an uploaded file when > executing the statement > > self.form = cgi.FieldStorage() > > I have taken great care not to use form['something'].value to make it > possible to upload large files but this does not help because the > problem occurs much earlier. > > Referring to the related problem mentioned above: I do not use Zope, > only the CGI module in the Python distribution. The file I upload does > contain a lot of new line characters. The mime encoded version of the > file should also contain new line characters. I have not (yet) checked > where in cgi.py the memory is used and what it is used for. > > I have been logging this with the following code on Linux: > > def log(self, info): > # get the process size from the proc fs - will work only on linux: > pid = os.getpid() > pstat = open(os.path.join('/proc', '%s' % pid, 'stat')).read() > size = string.atoi(string.split(pstat)[22]) / 1024 > # append some information to the log file: > where = string.rstrip(traceback.format_stack()[-2]) > where = string.split(where, '\n')[:1] > self.logfile.write('pid=%s, size=%s, At %s: %s\n' > % (pid, size, where, info)) > self.logfile.flush() > > only to realize the problem must be in cgi.py. Is this a known problem > and is there a fix for it? Can I do anything to get this fixed in > future distributions of Python? > > Thanks in advance for Your help. > From naris@ensim.com Thu Aug 24 20:11:10 2000 From: naris@ensim.com (naris@ensim.com) Date: Thu, 24 Aug 2000 15:11:10 -0400 (EDT) Subject: [Python-bugs-list] Re: The Python 1.5.2 cgi module chews up memory (PR#439) Message-ID: <20000824191110.DEBD61D2B5@dinsdale.python.org> actually, the cgi.py in the py dist has the read_lines_to_outerboundary function, which contains the bug. remove the self.lines.append(line) from the function and it should fix the bloat. let me know how if it works out. On Thu, 24 Aug 2000, Guenter Radestock wrote: > Hello, > > I have a problem with one of my Python CGIs and am not sure what to do > about this. I have found a related message in the bug reporting system > but do not know how to use this system to enter my problem so I will > describe it in this mail. > > URL of related problem: > http://www.python.org/python-bugs/notabug?id=396;expression=FieldStorage;user=guest > > My application grows to about twice the size of an uploaded file when > executing the statement > > self.form = cgi.FieldStorage() > > I have taken great care not to use form['something'].value to make it > possible to upload large files but this does not help because the > problem occurs much earlier. > > Referring to the related problem mentioned above: I do not use Zope, > only the CGI module in the Python distribution. The file I upload does > contain a lot of new line characters. The mime encoded version of the > file should also contain new line characters. I have not (yet) checked > where in cgi.py the memory is used and what it is used for. > > I have been logging this with the following code on Linux: > > def log(self, info): > # get the process size from the proc fs - will work only on linux: > pid = os.getpid() > pstat = open(os.path.join('/proc', '%s' % pid, 'stat')).read() > size = string.atoi(string.split(pstat)[22]) / 1024 > # append some information to the log file: > where = string.rstrip(traceback.format_stack()[-2]) > where = string.split(where, '\n')[:1] > self.logfile.write('pid=%s, size=%s, At %s: %s\n' > % (pid, size, where, info)) > self.logfile.flush() > > only to realize the problem must be in cgi.py. Is this a known problem > and is there a fix for it? Can I do anything to get this fixed in > future distributions of Python? > > Thanks in advance for Your help. > From noreply@sourceforge.net Fri Aug 25 04:04:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 24 Aug 2000 20:04:21 -0700 Subject: [Python-bugs-list] [Bug #112693] re behaves differently in 1.6 and 2.0 than 1.52 Message-ID: <200008250304.UAA13210@bush.i.sourceforge.net> Bug #112693, was updated on 2000-Aug-24 20:04 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: re behaves differently in 1.6 and 2.0 than 1.52 Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0 http://dorb.com/python/testRe.py For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112693&group_id=5470 From noreply@sourceforge.net Fri Aug 25 12:36:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 04:36:06 -0700 Subject: [Python-bugs-list] [Bug #112573] test_re crashes when compiled with -DPy_DEBUG Message-ID: <200008251136.EAA29699@bush.i.sourceforge.net> Bug #112573, was updated on 2000-Aug-23 11:57 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Wont Fix Bug Group: None Priority: 7 Summary: test_re crashes when compiled with -DPy_DEBUG Details: ./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 Test engine limitations maximum recursion limit exceeded FATAL: node type 304, required 310 Aborted (core dumped) bitdiddle:~/src/python/dist/src/build-Py_DEBUG> Follow-Ups: Date: 2000-Aug-25 04:36 By: effbot Comment: caused by broken assertions in the compiler, not SRE itself. see discussion on python-dev. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112573&group_id=5470 From noreply@sourceforge.net Fri Aug 25 12:36:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 04:36:40 -0700 Subject: [Python-bugs-list] [Bug #112573] test_re crashes when compiled with -DPy_DEBUG Message-ID: <200008251136.EAA29801@bush.i.sourceforge.net> Bug #112573, was updated on 2000-Aug-23 11:57 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Wont Fix Bug Group: None Priority: 7 Summary: test_re crashes when compiled with -DPy_DEBUG Details: ./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 Test engine limitations maximum recursion limit exceeded FATAL: node type 304, required 310 Aborted (core dumped) bitdiddle:~/src/python/dist/src/build-Py_DEBUG> Follow-Ups: Date: 2000-Aug-25 04:36 By: effbot Comment: caused by broken assertions in the compiler, not SRE itself. see discussion on python-dev. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112573&group_id=5470 From noreply@sourceforge.net Fri Aug 25 12:37:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 04:37:38 -0700 Subject: [Python-bugs-list] [Bug #112693] re behaves differently in 1.6 and 2.0 than 1.52 Message-ID: <200008251137.EAA29834@bush.i.sourceforge.net> Bug #112693, was updated on 2000-Aug-24 20:04 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: re behaves differently in 1.6 and 2.0 than 1.52 Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0 http://dorb.com/python/testRe.py For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112693&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:03:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:03:44 -0700 Subject: [Python-bugs-list] [Bug #110708] bug in time.sleep (PR#64) Message-ID: <200008251403.HAA24281@delerium.i.sourceforge.net> Bug #110708, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 3 Summary: bug in time.sleep (PR#64) Details: Jitterbug-Id: 64 Submitted-By: ddula@atl.mediaone.net Date: Wed, 25 Aug 1999 14:02:51 -0400 (EDT) Version: 152c1 OS: Debian Alpha Linux (potato) 2.2.1 This is a interesting bug that seems to have started after I upgraded to debian potato from slink. It must be a library related bug but this report might help somebody troubleshoot. At first I thought it was a bug in threading because it prevented the solaris hack sleep from returning thus my thread.start() never returned. But further digging show that import time time.sleep(0.1) # will always hang on on this platform Work around is to always sleep at least one second - I will do some more looking at the time class when I get a chance. Dave Dula ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:15 1999 guido changed notes Follow-Ups: Date: 2000-Aug-25 07:03 By: jhylton Comment: I poked the original contributor. If he responds, I'll raise the priority. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110708&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:08:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:08:10 -0700 Subject: [Python-bugs-list] [Bug #110778] pyport.h compile error on windows Message-ID: <200008251408.HAA24464@delerium.i.sourceforge.net> Bug #110778, was updated on 2000-Aug-01 09:01 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 7 Summary: pyport.h compile error on windows Details: pyport.h contains the following line, previously from myselect.h #define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */ On windows, NBBY is not defined (Im not sure who is supposed to define it). myselect.h was never included on windows, so this had never previously been a problem Follow-Ups: Date: 2000-Aug-02 02:32 By: htrd Comment: This is fixed in CVS revision 2.10 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110778&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:08:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:08:58 -0700 Subject: [Python-bugs-list] [Bug #110819] test suite incomplete (PR#1) Message-ID: <200008251408.HAA24483@delerium.i.sourceforge.net> Bug #110819, was updated on 2000-Aug-01 14:09 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: Remind Bug Group: Feature Request Priority: 1 Summary: test suite incomplete (PR#1) Details: Jitterbug-Id: 1 Submitted-By: guido@python.org Date: Mon, 3 May 1999 17:31:27 -0400 (EDT) Version: any OS: any Subject says it all. Not everything is tested. ==================================================================== Audit trail: Mon May 03 18:01:53 1999 guido sent reply 1 Mon Jul 12 15:33:07 1999 guido moved from incoming to request Mon Jul 12 19:09:04 1999 guido changed notes Follow-Ups: Date: 2000-Aug-01 14:10 By: none Comment: From: Guido van Rossum Subject: Re: test suite incomplete (PR#1) Date: Mon May 3 18:01:53 1999 I know, I know... ------------------------------------------------------- Date: 2000-Aug-01 14:10 By: none Comment: Of course, it's not likely that this will ever by completely resolved... :-) ------------------------------------------------------- Date: 2000-Aug-01 17:45 By: jhylton Comment: Thought you'd like to have this one assigned to you, Skip . ------------------------------------------------------- Date: 2000-Aug-05 06:03 By: montanaro Comment: as if i didn't have enough to do... ;-) maybe this is a good excuse to look at pyUnit. More tests might get written with a more easily used testing framework. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110819&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:09:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:09:57 -0700 Subject: [Python-bugs-list] [Bug #110834] urlparse and HTTP parameters (PR#205) Message-ID: <200008251409.HAA24595@delerium.i.sourceforge.net> Bug #110834, was updated on 2000-Aug-01 14:13 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: Later Bug Group: Feature Request Priority: 3 Summary: urlparse and HTTP parameters (PR#205) Details: Jitterbug-Id: 205 Submitted-By: mnot@akamai.com Date: Tue, 15 Feb 2000 17:09:44 -0500 (EST) Version: 1.5.2 OS: All 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... ==================================================================== Audit trail: Wed Feb 23 21:39:30 2000 guido sent reply 1 Wed Feb 23 21:39:42 2000 guido changed notes Wed Feb 23 21:39:42 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:13 By: none Comment: From: Guido van Rossum Subject: Re: urlparse and HTTP parameters (PR#205) Date: Wed Feb 23 21:39:30 2000 Go for it! --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 14:13 By: none Comment: Go for it! ------------------------------------------------------- Date: 2000-Aug-16 19:02 By: fdrake Comment: An excellent idea; it can be incorporated in the existing urlparse module using new names. This won't be done for Python 2.0 at any rate, however. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110834&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:10:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:10:30 -0700 Subject: [Python-bugs-list] [Bug #110839] PRIVATE: CGIHTTPServer (PR#239) Message-ID: <200008251410.HAA24601@delerium.i.sourceforge.net> Bug #110839, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: PRIVATE: CGIHTTPServer (PR#239) Details: Jitterbug-Id: 239 Submitted-By: Michael_Frericks@informatik-kooperation.de Date: Fri, 17 Mar 2000 11:27:23 -0500 (EST) Version: 1.5.2 OS: WinNT 4.0 The module CGIHTTPServer does not run on WinNT since a) the function executable() seems to return a false value, if you omit the call of executable() you come to b) the function nobody_uid() imports the module pwd available only for unix c) other unix-functions as fork... are used to create a process with the user nobody ==================================================================== Audit trail: Mon Apr 03 18:39:48 2000 guido changed notes Mon Apr 03 18:39:48 2000 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-01 14:15 By: none Comment: This module still needs to be ported to Windows... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110839&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:13:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:13:23 -0700 Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on NT (PR#41) Message-ID: <200008251413.HAA24665@delerium.i.sourceforge.net> Bug #110843, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: Low FD_SETSIZE limit on NT (PR#41) Details: Jitterbug-Id: 41 Submitted-By: brian@digicool.com Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT) Version: 1.5.2 OS: NT It appears that win32 has a default limit of 64 descriptors that can be handed to the select() function. This is pretty low for any serious async servers, and causes them to raise lots of errors under very moderate loads. We at DC ran into this using Medusa as a basis for ZServer, which serves Zope sites. It turns out that you can actually add a define when compiling the python15.dll for windows to bump the default fd limit to a more reasonable level. The approach _I_ took was to add the define: FD_SETSIZE=1024 to the preprocessor options in the MSVC project settings for python15.dll, though I imagine you could also roll the define into config.h or something (so long as it's defined before windows.h or any of the select / socket include files are referenced). It would make life much easier for win32 server developers if this define could find its way into the next official python release :^) Thanks! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ==================================================================== Audit trail: Fri Jul 30 10:43:41 1999 guido moved from incoming to request For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110843&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:14:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:14:21 -0700 Subject: [Python-bugs-list] [Bug #110845] struct.pack not being very picky (PR#52) Message-ID: <200008251414.HAA24686@delerium.i.sourceforge.net> Bug #110845, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: struct.pack not being very picky (PR#52) Details: Jitterbug-Id: 52 Submitted-By: da@ski.org Date: Sun, 15 Aug 1999 17:52:20 -0400 (EDT) Version: 1.5.2 OS: NT4SP3 >>> from struct import * >>> struct.pack('B', -12) '\364' I expected a ValueError, the way: >>> struct.pack('c', 123) Traceback (innermost last): File "", line 1, in ? struct.error: char format require string of length 1 works. ==================================================================== Audit trail: Mon Aug 30 12:33:11 1999 guido moved from incoming to request For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110845&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:15:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:15:15 -0700 Subject: [Python-bugs-list] [Bug #110853] Segmentation fault with kernel 2.2.12 (PR#103) Message-ID: <200008251415.HAA24801@delerium.i.sourceforge.net> Bug #110853, was updated on 2000-Aug-01 14:37 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Irreproducible Priority: 1 Summary: Segmentation fault with kernel 2.2.12 (PR#103) Details: Jitterbug-Id: 103 Submitted-By: apsteffe@netwood.net Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT) Version: 1.5.2 OS: Linux 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 . ==================================================================== Audit trail: Mon Oct 18 18:08:00 1999 guido changed notes Mon Oct 18 18:08:00 1999 guido changed notification Mon Oct 18 18:08:00 1999 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:37 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Segmentation fault with kernel 2.2.12 (PR#103) Date: Mon, 11 Oct 1999 23:09:13 -0400 > 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/) ------------------------------------------------------- Date: 2000-Aug-01 14:37 By: none Comment: Probably caused by a huge jump in Linux kernel version without recompiling Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110853&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:15:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:15:58 -0700 Subject: [Python-bugs-list] [Bug #110855] test_array.py fails (PR#143) Message-ID: <200008251415.HAA24807@delerium.i.sourceforge.net> Bug #110855, was updated on 2000-Aug-01 14:37 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Irreproducible Priority: 1 Summary: test_array.py fails (PR#143) Details: Jitterbug-Id: 143 Submitted-By: ellement@sdd.hp.com Date: Thu, 2 Dec 1999 14:04:38 -0500 (EST) Version: 1.5.2 OS: HP-UX 10.20 After building python, 'make test' fails when test_array is run: > python Lib/test/test_array.py Traceback (innermost last): File "Lib/test/test_array.py", line 85, in ? main() File "Lib/test/test_array.py", line 10, in main testtype('c', 'c') File "Lib/test/test_array.py", line 21, in testtype a.append(example) AttributeError: '' object has no attribute 'append' Memory fault(coredump) How do I go about debugging this? ==================================================================== Audit trail: Fri Dec 03 10:38:53 1999 guido changed notes Fri Dec 03 10:38:53 1999 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:37 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] test_array.py fails (PR#143) Date: Thu, 02 Dec 1999 14:07:32 -0500 > Full_Name: David Ellement > Version: 1.5.2 > OS: HP-UX 10.20 > Submission from: sanrel1.sdd.hp.com (192.6.114.30) > > > After building python, 'make test' fails when test_array is run: > > > python Lib/test/test_array.py > Traceback (innermost last): > File "Lib/test/test_array.py", line 85, in ? > main() > File "Lib/test/test_array.py", line 10, in main > testtype('c', 'c') > File "Lib/test/test_array.py", line 21, in testtype > a.append(example) > AttributeError: '' object has no attribute 'append' > Memory fault(coredump) > > > How do I go about debugging this? Seems like a pretty serious problem in your build. Use a debugger (e.g. gdb). The bugs list is not the forum to discuss this, since the bug is likely in your installation and not in Python. Try comp.lang.python for help. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:37 By: none Comment: Build problems? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110855&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:18:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:18:24 -0700 Subject: [Python-bugs-list] [Bug #110862] linuxthreads lock failed (PR#322) Message-ID: <200008251418.HAA24860@delerium.i.sourceforge.net> Bug #110862, was updated on 2000-Aug-01 14:39 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Irreproducible Priority: 5 Summary: linuxthreads lock failed (PR#322) Details: Jitterbug-Id: 322 Submitted-By: wora2002@yahoo.com Date: Wed, 10 May 2000 01:21:26 -0400 (EDT) Version: 1.5.2 OS: Linux I am writing a multi-threaded python problem on linux. And the program consistently hang after 24 hours. From the debugger, I can see the linuxthreads pthread condvar waiting list is cyclic, and I believe the specific lock is the "tcl_lock". I guess the bug may related to signal handling or some race condition. hong ==================================================================== Audit trail: Mon May 22 17:33:29 2000 guido changed notes Tue Jul 11 08:29:17 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:39 By: none Comment: Hard to help... ------------------------------------------------------- Date: 2000-Aug-25 07:18 By: jhylton Comment: Is a bug report for threads under 1.5.2 likely to be relevent for 2.0? Or do we need to ask the author to reproduce under 2.0? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110862&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:22:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:22:17 -0700 Subject: [Python-bugs-list] [Bug #110857] it don't make (PR#269) Message-ID: <200008251422.HAA25017@delerium.i.sourceforge.net> Bug #110857, was updated on 2000-Aug-01 14:38 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Irreproducible Priority: 3 Summary: it don't make (PR#269) Details: Jitterbug-Id: 269 Submitted-By: mitch.harris@usa.net Date: Mon, 3 Apr 2000 13:29:25 -0400 (EDT) Version: 1.6 OS: sun 5.6 First time I tried to install Python. /usr2/t_mitchh/python/Python-1.6a1>version Machine hardware: sun4u OS version: 5.6 Processor type: sparc Hardware: SUNW,Ultra-1 The following components are installed on your system: Sun Visual WorkShop C++ 3.0 Sun WorkShop Compiler C 4.2 Sun WorkShop Compiler C++ 4.2 Sun WorkShop Tools.h++ 7.0 Sun WorkShop Tools.h++ 6.0.4 Sun WorkShop Visual 2.0 Sun WorkShop IPE 4.0 Sun WorkShop CodeManager 2.0 Sun WorkShop Distributed Make 2.0 Sun WorkShop FileMerge 3.0 Sun WorkShop FreezePoint 2.0 Sun WorkShop Maketool 2.0 Sun WorkShop VersionTool 2.0 Sun WorkShop Dbx 4.0 Sun WorkShop Performance Analyzer 4.0 Sun WorkShop LoopTool 2.1 Sun WorkShop LockLint 2.1 Sun WorkShop Thread Analyzer 1.2 Sun WorkShop XEmacs 20.00 /usr2/t_mitchh/python/Python-1.6a1>./configure creating cache ./config.cache checking MACHDEP... sunos5 checking for --without-gcc... no checking for --with-cxx=... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking LINKCC... $(PURIFY) $(CC) checking LDLIBRARY... checking for ranlib... ranlib checking for ar... ar checking how to run the C preprocessor... gcc -E checking for AIX... no checking for minix/config.h... no checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking for C preprocessor type... ansi checking for ANSI C header files... yes checking for dlfcn.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for locale.h... yes checking for ncurses.h... no checking for pthread.h... yes checking for signal.h... yes checking for stdarg.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for thread.h... yes checking for unistd.h... yes checking for utime.h... yes checking for sys/audioio.h... yes checking for sys/file.h... no checking for sys/lock.h... yes checking for sys/param.h... no checking for sys/select.h... yes checking for sys/time.h... yes checking for sys/times.h... yes checking for sys/un.h... yes checking for sys/utsname.h... yes checking for sys/wait.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for clock_t in time.h... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... void checking for size_t... yes checking for uid_t in sys/types.h... yes checking size of int... 4 checking size of long... 4 checking size of void *... 4 checking size of char... 1 checking size of short... 2 checking size of float... 4 checking size of double... 8 checking for long long support... yes checking size of long long... 8 checking size of off_t... 4 checking whether to enable large file support... no checking for --with-next-framework... no checking for --with-dyld... no checking SO... .so checking LDSHARED... ld -G checking CCSHARED... checking LINKFORSHARED... checking for dlopen in -ldl... yes checking for shl_load in -ldld... no checking for t_open in -lnsl... yes checking for socket in -lsocket... yes checking for socket in -lnet... no checking for --with-libs... no checking for --with(out)-readline... not specified. checking for --with-dec-threads... no checking for --with-threads... no checking for --with-thread... no checking for --with-sgi-dl... no checking for --with-dl-dld... no checking for dlopen... yes checking DYNLOADFILE... dynload_shlib.o checking for alarm... yes checking for chown... yes checking for clock... yes checking for confstr... yes checking for ctermid... yes checking for ctermid_r... yes checking for dlopen... (cached) yes checking for execv... yes checking for flock... no checking for fork... yes checking for fsync... yes checking for fdatasync... no checking for fpathconf... yes checking for ftime... yes checking for ftruncate... yes checking for getgroups... yes checking for getlogin... yes checking for getpeername... yes checking for getpgrp... yes checking for getpid... yes checking for getpwent... yes checking for gettimeofday... yes checking for getwd... yes checking for kill... yes checking for link... yes checking for lstat... yes checking for mkfifo... yes checking for mktime... yes checking for nice... yes checking for pathconf... yes checking for pause... yes checking for plock... yes checking for pthread_init... no checking for putenv... yes checking for readlink... yes checking for select... yes checking for setgid... yes checking for setlocale... yes checking for setuid... yes checking for setsid... yes checking for setpgid... yes checking for setpgrp... yes checking for setvbuf... yes checking for sigaction... yes checking for siginterrupt... yes checking for sigrelse... yes checking for strftime... yes checking for strptime... yes checking for symlink... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for tcsetpgrp... yes checking for tempnam... yes checking for timegm... no checking for times... yes checking for tmpfile... yes checking for tmpnam... yes checking for tmpnam_r... yes checking for truncate... yes checking for uname... yes checking for waitpid... yes checking for fseek64... no checking for fseeko... yes checking for fstatvfs... yes checking for ftell64... no checking for ftello... yes checking for statvfs... yes checking for dup2... yes checking for getcwd... yes checking for strdup... yes checking for strerror... yes checking for memmove... yes checking for getpgrp... (cached) yes checking for setpgrp... (cached) yes checking for gettimeofday... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for tm_zone in struct tm... no checking for tzname... yes checking for time.h that defines altzone... yes checking whether sys/select.h and sys/time.h may both be included... yes checking whether char is unsigned... no checking for working const... yes checking for inline... inline checking for working volatile... yes checking for working signed char... yes checking for prototypes... yes checking for variable length prototypes and stdarg.h... yes checking for bad exec* prototypes... no checking for bad static forward... no checking whether va_list is an array... no checking for gethostbyname_r... yes checking gethostbyname_r with 6 args... no checking gethostbyname_r with 5 args... no checking gethostbyname_r with 3 args... no checking for __fpu_control in -lieee... no checking for --with-fpectl... no checking for --with-libm=STRING... default LIBM="-lm" checking for --with-libc=STRING... default LIBC="" checking for hypot... yes checking for hypot... (cached) yes checking for genuine getopt... yes checking what malloc(0) returns... nonnull checking for wchar.h... yes checking for usable wchar_t... no checking whether byte ordering is bigendian... yes checking for --with-wctype-functions... no updating cache ./config.cache creating ./config.status creating Makefile creating Objects/Makefile creating Parser/Makefile creating Python/Makefile creating Modules/Makefile.pre creating Modules/Setup.thread creating config.h /usr2/t_mitchh/python/Python-1.6a1/Modules>make gcc -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./posixmodule.c In file included from ./posixmodule.c:3194: /usr/include/sys/statvfs.h:38: parse error before `fsblkcnt_t' /usr/include/sys/statvfs.h:38: warning: no semicolon at end of struct or union /usr/include/sys/statvfs.h:39: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:40: parse error before `f_bavail' /usr/include/sys/statvfs.h:40: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:41: parse error before `f_files' /usr/include/sys/statvfs.h:41: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:42: parse error before `f_ffree' /usr/include/sys/statvfs.h:42: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:43: parse error before `f_favail' /usr/include/sys/statvfs.h:43: warning: data definition has no type or storage class /usr/include/sys/statvfs.h:51: parse error before `}' /usr/include/sys/statvfs.h:51: warning: data definition has no type or storage class ./posixmodule.c: In function `posix_fstatvfs': ./posixmodule.c:3207: storage size of `st' isn't known ./posixmodule.c: In function `posix_statvfs': ./posixmodule.c:3259: storage size of `st' isn't known make: *** [posixmodule.o] Error 1 I tried this #if defined(HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) #if defined(HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) #ifdef HAVE_FSTATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #ifdef HAVE_STATVFSxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx and got this /prj/qed2/local//lib/gcc-lib/sparc-sun-solaris2.5/2.7.2.1/include/sys/param.h:187: warning: `NBBY' r /usr/include/sys/select.h:45: warning: this is the location of the previous definition In file included from /usr/include/sys/stream.h:26, from /usr/include/netinet/in.h:38, from /usr/include/netdb.h:96, from ./socketmodule.c:163: /usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified" make[1]: *** [socketmodule.o] Error 1 make[1]: Leaving directory `/usr2/t_mitchh/python/Python-1.6a1/Modules' make: *** [Modules] Error 2 ==================================================================== Audit trail: Mon May 22 17:44:30 2000 guido changed notes Mon May 22 17:44:30 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:38 By: none Comment: Sun's compiler sucks? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110857&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:27:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:27:54 -0700 Subject: [Python-bugs-list] [Bug #110854] Re: Date problem unresolved [DIN 2646] (fwd) (PR#109) Message-ID: <200008251427.HAA25249@delerium.i.sourceforge.net> Bug #110854, was updated on 2000-Aug-01 14:37 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Irreproducible Priority: 3 Summary: Re: Date problem unresolved [DIN 2646] (fwd) (PR#109) Details: Jitterbug-Id: 109 Submitted-By: Curt Finch Date: Thu, 14 Oct 1999 14:58:08 -0500 (CDT) Version: None OS: None 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 > > > > > > > > > > > > > > > ==================================================================== Audit trail: Mon Oct 18 17:53:07 1999 guido changed notes Mon Oct 18 17:53:07 1999 guido changed notification Mon Oct 18 17:53:08 1999 guido moved from incoming to open Tue Oct 19 00:42:35 1999 guido changed notes Tue Oct 19 00:42:37 1999 guido moved from open to irreproducible Follow-Ups: Date: 2000-Aug-01 14:37 By: none Comment: Can't reproduce this here. Your best bet is to look into the conversion of the time() value to floating point -- maybe you are using a bogus floating point emulation? BTW, forwarding such a long thread of email without a clear summary of the problem at the top makes it hard for me to read the bug report. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110854&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:31:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:31:00 -0700 Subject: [Python-bugs-list] [Bug #110863] Reference counting problem? (PR#338) Message-ID: <200008251431.HAA25387@delerium.i.sourceforge.net> Bug #110863, was updated on 2000-Aug-01 14:39 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Irreproducible Priority: 1 Summary: Reference counting problem? (PR#338) Details: Jitterbug-Id: 338 Submitted-By: gpk@bell-labs.com Date: Wed, 24 May 2000 10:24:32 -0400 (EDT) Version: 1.6 as of 5/21/2000 OS: Solaris 2.6 Python 1.6 seems to have some kind of reference counting problem. The following function (in the midst of a large program) will crash with a nonsensical exception if I comment out the print statement. def _pull_types(d, nc): """Finds all the column definitions in the data file, that is, attributes in the form 'TTYPE#'. These attributes tell you what kind of data is in a specific column. It then builds an output dictionary that tells you what column contains any desired type of data.""" ts = type('') kl = d.keys() o = {} for k in kl: assert type(k)==ts, 'Key must be string' # comment out next line to crash: print "PULLTYPES(", k, ")", 'type(k)=', type(k) if len(k)>5 and k[:5] == 'TTYPE': col = string.atoi(k[5:]) if col>0 and col<=nc: o[d[k]] = col-1 return o Output with print statement in: ... PULLTYPES( HISTORY ) type(k)= PULLTYPES( _FILETYPE ) type(k)= PULLTYPES( I_NOISE ) type(k)= PULLTYPES( NAXIS2 ) type(k)= PULLTYPES( CDELT2 ) type(k)= PULLTYPES( CDELT1 ) type(k)= ... Output with print statement commented out: ... Traceback (most recent call last): File "/u/gpk/f0cls/bin/get_3_f0.sh", line 101, in ? pegg = get_f0(t + '/pegg.sd', pfile+'.pegg', t + '/pegg'); File "/u/gpk/f0cls/bin/get_3_f0.sh", line 83, in get_f0 return gpkimgclass.read(ttn + '.f0.dat') File "/home/gpk/lib/gpkimgclass.py", line 41, in read return gpk_img(hdr, data) File "/home/gpk/lib/gpkimgclass.py", line 69, in __init__ self.types = _pull_types(self.hdr, self.n[1]) File "/home/gpk/lib/gpkimgclass.py", line 23, in _pull_types if len(k)>5 and k[:5] == 'TTYPE': IndexError: list index out of range ... ==================================================================== Audit trail: Tue Jul 11 08:29:19 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:39 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Reference counting problem? (PR#338) Date: Thu, 25 May 2000 16:49:09 -0500 > Python 1.6 seems to have some kind of reference counting problem. > > The following function (in the midst of a large program) > will crash with a nonsensical exception if I comment out the > print statement. Without the whole program and its input data it's hard to debug this. Does your program use any nonstandard extension modules? That's where I'd start looking... A bug in core Python, while not impossible, is pretty unlikely. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:39 By: none Comment: From: Greg Kochanski Subject: Re: [Python-bugs-list] Reference counting problem? (PR#338) Date: Fri, 26 May 2000 11:36:51 -0400 Guido van Rossum wrote: > > > Python 1.6 seems to have some kind of reference counting problem. > > Without the whole program and its input data it's hard to debug this. > Does your program use any nonstandard extension modules? That's where > I'd start looking... It does. Some of the input data is a copy of a directory the nonstandard module produces. I'll look at the nonstandard module, and also see if I can isolate the problem to a reasonable-size chunk of code. ------------------------------------------------------- Date: 2000-Aug-25 07:31 By: jhylton Comment: Will close this one unless the original poster reponds. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110863&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:37:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:37:36 -0700 Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate Message-ID: <200008251437.HAA25650@delerium.i.sourceforge.net> Bug #111403, was updated on 2000-Aug-08 11:26 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: 1.6b1 dumps core dereferencing a NULL tstate Details: This is from an embeded python. I've not yet been able to reproduce this with a small example. But perhaps this stacktrace will be of some help. The problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back. This pointer is dereferenced in PyFrame_New() later on which causes the core dump. The documentation seems to say that PyThreadState_GET() should never return NULL. So, there must be a bug in there somewhere. Here is the stack trace: #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 120 PyFrameObject *back = tstate->frame; (gdb) bt #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 #1 0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x925d2e8) at ceval.c:397 #2 0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0) at ceval.c:2521 #3 0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, kw=0x0) at ceval.c:2359 #4 0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0) at abstract.c:1370 #5 0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80) at DrawingArea.C:971 #6 0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027 #7 0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169 #8 0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1) at ./tclUnixNotfy.c:405 #9 0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444 #10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747 #11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0) at ./_tkinter.c:1794 #12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2396 #13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2361 #14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, defcount=1, owner=0x0) at ceval.c:1680 #15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, defcount=0, owner=0x92c6238) at ceval.c:1579 #16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038) at ceval.c:290 #19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885 #20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870 #21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847 #22 0x867ce4e in PyRun_SimpleString ( command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589 #23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248 #24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30 Mike Romberg (romberg@fsl.noaa.gov) Follow-Ups: Date: 2000-Aug-10 10:23 By: none Comment: Followup: This only happens when python is built --with-threads. There appears to be no problem when threads are not enabled. It should be noted that our embeded application uses no threads of any kind (python or pthreads from C++). But it may be the case that our code (C++) is not doing the right thing. It should be noted that our application works fine with python-1.5.2 compiled --with-threads. ------------------------------------------------------- Date: 2000-Aug-25 07:37 By: jhylton Comment: Mike -- Can you provide any more information about this bug? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:42:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:42:18 -0700 Subject: [Python-bugs-list] [Bug #112693] re behaves differently in 1.6 and 2.0 than 1.52 Message-ID: <200008251442.HAA25849@delerium.i.sourceforge.net> Bug #112693, was updated on 2000-Aug-24 20:04 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: re behaves differently in 1.6 and 2.0 than 1.52 Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0 http://dorb.com/python/testRe.py Follow-Ups: Date: 2000-Aug-25 07:42 By: jhylton Comment: Just noting that we should resolve this bug before release. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112693&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:42:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:42:50 -0700 Subject: [Python-bugs-list] [Bug #112468] sre/pre bug Message-ID: <200008251442.HAA25877@delerium.i.sourceforge.net> Bug #112468, was updated on 2000-Aug-21 22:05 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 7 Summary: sre/pre bug Details: Compiling the simple pattern '(' with pre raises an exception while sre compiles it sucessfully. Further, the regex object that sre.compile returns will match any string. Using Python 1.6b1 (#0, Aug 7 2000, 12:30:24) [MSC 32 bit (Intel)] on win32, >>> import sre >>> regex_ = sre.compile('(') >>> regex_.pattern '(' >>> regex_.search('abc').group(0) '' while >>> import pre >>> regex_ = pre.compile('(') Traceback (most recent call last): File "", line 1, in ? File "C:\Python16\lib\pre.py", line 243, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('missing )', 1) Follow-Ups: Date: 2000-Aug-22 05:34 By: gvanrossum Comment: According to Fredrik, this is a minor parsing bug in SRE. He'll fix it. ------------------------------------------------------- Date: 2000-Aug-25 07:42 By: jhylton Comment: Bumping priority so its gets fixed before release. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112468&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:43:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:43:02 -0700 Subject: [Python-bugs-list] [Bug #112123] bdist_wininst crashes with no long_description Message-ID: <200008251443.HAA25880@delerium.i.sourceforge.net> Bug #112123, was updated on 2000-Aug-16 15:18 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Summary: bdist_wininst crashes with no long_description Details: The bdist_wininst command crashes if no long_description is specified: File "setup.py", line 48, in ? sources = [ File "/www/python/lib/python1.5/site-packages/distutils/core.py", line 112, in setup dist.run_commands () File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 776, in run_commands self.run_command (cmd) File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 797, in run_command cmd_obj.run () File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 115, in run self.create_exe (arcname, fullname) File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 171, in create_exe cfgdata = open (self.create_inifile()).read() File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 140, in create_inifile info = metadata.long_description + '\n' TypeError: bad operand type(s) for + For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112123&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:41:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:41:23 -0700 Subject: [Python-bugs-list] [Bug #110867] DCOracle select max() always returns integers (PR#289) Message-ID: <200008251441.HAA25831@delerium.i.sourceforge.net> Bug #110867, was updated on 2000-Aug-01 14:41 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: DCOracle select max() always returns integers (PR#289) Details: Jitterbug-Id: 289 Submitted-By: bchen@exelixis.com Date: Tue, 11 Apr 2000 18:52:54 -0400 (EDT) Version: 1.5.2 OS: SUN Solaris I am using DCOracle to retrieve the max and min values of an attribute from a database. The attribute contains floating point numbers. If I use select attr_name from table_name I got a list of floating point numbers. But if I call select max(attr_name) from table_name I always got integers. Can anyone help me figure out what's wrong? Thanks, Bin ==================================================================== Audit trail: Sat Jul 01 02:44:48 2000 fdrake moved from incoming to 3rdpartybug Follow-Ups: Date: 2000-Aug-25 07:41 By: jhylton Comment: Ken-- Can you forward this report to someone at DC and then close the Python bug? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110867&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:44:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:44:08 -0700 Subject: [Python-bugs-list] [Bug #112317] os.rename transparent handling of cross-filesystem issues Message-ID: <200008251444.HAA25894@delerium.i.sourceforge.net> Bug #112317, was updated on 2000-Aug-19 10:09 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: os.rename transparent handling of cross-filesystem issues Details: On some systems (specifically, Linux), the rename system call will throw an EXDEV error if rename is used across filesystems. It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do). The benefits of this. . .getting rid of code like the following: try: os.rename('ff','/tmp/ff') except: open('/tmp/ff','w').write(open('ff','r').read()) os.unlink('ff') Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem. I took a quick look at posixmodule.c. A quick hack changes posix_2str's signature to the following: PyObject *args char *format int (*func)(const char*, const char *) int (*special_handler)(const char *, const char *) and the inner function to: if (res != 0) if ((! special_handler) || (*special_handler)(path1,path2)) return posix_error() Of course, then a smart copy routine (includes an unlink step). The most unclear thing at this point is what to do with the errno. Would a failure in the errorhandler report the original errno or its own errno??? Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method. Follow-Ups: Date: 2000-Aug-25 07:44 By: jhylton Comment: revisit this after 2.0 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112317&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:44:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:44:45 -0700 Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue Message-ID: <200008251444.HAA25908@delerium.i.sourceforge.net> Bug #112289, was updated on 2000-Aug-18 19:50 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: NetBSD1.4.2 build issue Details: the recent fileobjects.c work done for large files (tmick) appears broken when compiled against NetBSD1.4.2. During the final link, you get the following output: gcc python.o ../libpython2.0.a -lutil -lm -o python fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment Follow-Ups: Date: 2000-Aug-18 19:55 By: none Comment: NOTE: I didn't include the configure output. If that would be helpful, go ahead and indicate that in this tracking system. If tmick (or whoever) would like me to contact them directly, I would happily do so. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:45:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:45:13 -0700 Subject: [Python-bugs-list] [Bug #110862] linuxthreads lock failed (PR#322) Message-ID: <200008251445.HAA26010@delerium.i.sourceforge.net> Bug #110862, was updated on 2000-Aug-01 14:39 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: None Bug Group: Irreproducible Priority: 5 Summary: linuxthreads lock failed (PR#322) Details: Jitterbug-Id: 322 Submitted-By: wora2002@yahoo.com Date: Wed, 10 May 2000 01:21:26 -0400 (EDT) Version: 1.5.2 OS: Linux I am writing a multi-threaded python problem on linux. And the program consistently hang after 24 hours. From the debugger, I can see the linuxthreads pthread condvar waiting list is cyclic, and I believe the specific lock is the "tcl_lock". I guess the bug may related to signal handling or some race condition. hong ==================================================================== Audit trail: Mon May 22 17:33:29 2000 guido changed notes Tue Jul 11 08:29:17 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:39 By: none Comment: Hard to help... ------------------------------------------------------- Date: 2000-Aug-25 07:18 By: jhylton Comment: Is a bug report for threads under 1.5.2 likely to be relevent for 2.0? Or do we need to ask the author to reproduce under 2.0? ------------------------------------------------------- Date: 2000-Aug-25 07:45 By: tim_one Comment: I see no evidence of a Python bug here. Do you? There isn't enough info here for us to do anything, so I'm just closing it without resolution. If the submitter would like to supply a minimal failing test case, cool, we can reopen it then. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110862&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:45:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:45:17 -0700 Subject: [Python-bugs-list] [Bug #112265] Impossible to get Win32 default font encoding in widgets Message-ID: <200008251445.HAA26015@delerium.i.sourceforge.net> Bug #112265, was updated on 2000-Aug-18 13:37 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: Platform-specific Priority: 6 Summary: Impossible to get Win32 default font encoding in widgets Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly. As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:48:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:48:05 -0700 Subject: [Python-bugs-list] [Bug #112244] time.strptime() not present in Python 1.5.2 for MSWin Message-ID: <200008251448.HAA26068@delerium.i.sourceforge.net> Bug #112244, was updated on 2000-Aug-18 06:54 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: time.strptime() not present in Python 1.5.2 for MSWin Details: Using Python 1.5.2 for MSWin, any attempt to use the time.strptime() function from the time module results in the error: AttributeError: strptime This error does not occur for the Unix version of Python 1.5.2. Follow-Ups: Date: 2000-Aug-18 10:38 By: tim_one Comment: Changed to group Feature Request. strptime is available from Python only on those platforms where this (non-standard) C function happens to be available from the platform C library. Windows is not one of those. Not all Unix versions have it either. The docs already say that. The only way it will become available is if someone contributes an implementation. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112244&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:55:26 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:55:26 -0700 Subject: [Python-bugs-list] [Bug #111481] os.stat() doesn't return st_rdev Message-ID: <200008251455.HAA04370@bush.i.sourceforge.net> Bug #111481, was updated on 2000-Aug-09 06:38 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: os.stat() doesn't return st_rdev Details: The call os.stat() returns the fields st_mode, st_ino, st_nlink, st_uid, st_gid, st_size, st_atime, st_mtime st_ctime from "struct stat". To be able to explore device nodes on a linux system the field st_rdev needed as the major and minor device number is stored in this field. It would be nice if it could be added as an extra element in the tuple returned by os.stat, os.lstat etc. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111481&group_id=5470 From noreply@sourceforge.net Fri Aug 25 15:57:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 07:57:40 -0700 Subject: [Python-bugs-list] [Bug #110840] -with-cxx option to configure script (PR#24) Message-ID: <200008251457.HAA04487@bush.i.sourceforge.net> Bug #110840, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: -with-cxx option to configure script (PR#24) Details: Jitterbug-Id: 24 Submitted-By: guido@python.org Date: Wed, 14 Jul 1999 11:16:51 -0400 (EDT) Version: 1.5.2 OS: Unix Geoff Furnish has a patch for the configure script which might be reasonable. See http://www.python.org/sigs/c++-sig/sig_code.html ==================================================================== Audit trail: Wed Jul 14 11:18:10 1999 guido moved from incoming to request For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110840&group_id=5470 From noreply@sourceforge.net Fri Aug 25 16:04:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 08:04:49 -0700 Subject: [Python-bugs-list] [Bug #112113] Built-in exception class not found: UnboundLocalError. Message-ID: <200008251504.IAA04713@bush.i.sourceforge.net> Bug #112113, was updated on 2000-Aug-16 12:12 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: Built-in exception class not found: UnboundLocalError. Details: I've just compiled Python-1.6b1 for QNX4.25 and QNX/Neutrino 2.1. The Neutrino port works ... but the QNX 4.25 port make problems: # ./python Built-in exception class not found: UnboundLocalError. Library mismatch? Fatal Python error: Standard exceptions could not be initialized. %1 19800 Abort ./python # The lookdict() call returns a NULL value in the init phase of python. Any tips for fixing that problem? Regards Armin Steinhoff Armin@Steinhoff.de Follow-Ups: Date: 2000-Aug-17 06:39 By: none Comment: QNX/Neutrino was compiled with -> GNU gcc QNX 4.25 with -> Watcom 10.6 Armin ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112113&group_id=5470 From noreply@sourceforge.net Fri Aug 25 16:11:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 08:11:32 -0700 Subject: [Python-bugs-list] [Bug #111961] urllib.quote and string.letters Message-ID: <200008251511.IAA04930@bush.i.sourceforge.net> Bug #111961, was updated on 2000-Aug-15 07:31 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urllib.quote and string.letters Details: urllib.quote() uses string.letters for determining, if a character is save to be used in an url. In Python 1.5.2. this was only 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'. This seems to have changed in Python1.6b1 (or maybe it is the responsibility of the locale module) to 'abcdefghijklmnopqrstuvwxyz\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\ 370\371\372\373\374\375\376\377ABCDEFGHIJKLMNOPQRSTUVWXYZ\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\32 0\321\322\323\324\325\326\330\331\332\333\334\335\336' which changes the semantics of urllib.quote() For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111961&group_id=5470 From noreply@sourceforge.net Fri Aug 25 16:39:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 08:39:14 -0700 Subject: [Python-bugs-list] [Bug #111928] obsolete use of socket.connect() Message-ID: <200008251539.IAA06017@bush.i.sourceforge.net> Bug #111928, was updated on 2000-Aug-14 19:09 Here is a current snapshot of the bug. Project: Python Category: demos and tools Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: obsolete use of socket.connect() Details: in 1.6b1 tree under "Demo/sockets", there are obsolete use of socket.connect() still present. Index: Demo/sockets/finger.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/finger.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 finger.py --- Demo/sockets/finger.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/finger.py 2000/08/15 02:08:12 @@ -23,7 +23,7 @@ # def finger(host, args): s = socket(AF_INET, SOCK_STREAM) - s.connect(host, FINGER_PORT) + s.connect((host, FINGER_PORT)) s.send(args + '\n') while 1: buf = s.recv(1024) Index: Demo/sockets/ftp.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/ftp.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 ftp.py --- Demo/sockets/ftp.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/ftp.py 2000/08/15 02:08:12 @@ -48,7 +48,7 @@ # Create control connection # s = socket(AF_INET, SOCK_STREAM) - s.connect(hostname, FTP_PORT) + s.connect((hostname, FTP_PORT)) f = s.makefile('r') # Reading the replies is easier from a file... # # Control loop @@ -79,7 +79,7 @@ port = nextport + FTP_DATA_PORT nextport = (nextport+1) % 16 r = socket(AF_INET, SOCK_STREAM) - r.bind(gethostbyname(gethostname()), port) + r.bind((gethostbyname(gethostname()), port)) r.listen(1) sendportcmd(s, f, port) return r Index: Demo/sockets/telnet.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/telnet.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 telnet.py --- Demo/sockets/telnet.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/telnet.py 2000/08/15 02:08:12 @@ -51,7 +51,7 @@ s = socket(AF_INET, SOCK_STREAM) # try: - s.connect(host, port) + s.connect((host, port)) except error, msg: sys.stderr.write('connect failed: ' + `msg` + '\n') sys.exit(1) Index: Demo/sockets/throughput.py =================================================================== RCS file: /cvsroot/apps/python/Demo/sockets/throughput.py,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 throughput.py --- Demo/sockets/throughput.py 1999/04/13 10:01:42 1.1.1.1 +++ Demo/sockets/throughput.py 2000/08/15 02:08:12 @@ -72,7 +72,7 @@ t1 = time.time() s = socket(AF_INET, SOCK_STREAM) t2 = time.time() - s.connect(host, port) + s.connect((host, port)) t3 = time.time() i = 0 while i < count: Follow-Ups: Date: 2000-Aug-25 08:39 By: jhylton Comment: There were a few more calls to bind that also needed to be fixed. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111928&group_id=5470 From noreply@sourceforge.net Fri Aug 25 16:39:49 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 08:39:49 -0700 Subject: [Python-bugs-list] [Bug #110867] DCOracle select max() always returns integers (PR#289) Message-ID: <200008251539.IAA28038@delerium.i.sourceforge.net> Bug #110867, was updated on 2000-Aug-01 14:41 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: DCOracle select max() always returns integers (PR#289) Details: Jitterbug-Id: 289 Submitted-By: bchen@exelixis.com Date: Tue, 11 Apr 2000 18:52:54 -0400 (EDT) Version: 1.5.2 OS: SUN Solaris I am using DCOracle to retrieve the max and min values of an attribute from a database. The attribute contains floating point numbers. If I use select attr_name from table_name I got a list of floating point numbers. But if I call select max(attr_name) from table_name I always got integers. Can anyone help me figure out what's wrong? Thanks, Bin ==================================================================== Audit trail: Sat Jul 01 02:44:48 2000 fdrake moved from incoming to 3rdpartybug Follow-Ups: Date: 2000-Aug-25 07:41 By: jhylton Comment: Ken-- Can you forward this report to someone at DC and then close the Python bug? ------------------------------------------------------- Date: 2000-Aug-25 08:39 By: klm Comment: I've forwarded this to someone at digital creations, who will include it in the bug report mechanism here - for future reference, that's: http://classic.zope.org:8080/Collector (Bin, you may want to check the collector for bug reports related to the one you submitted.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110867&group_id=5470 From noreply@sourceforge.net Fri Aug 25 16:41:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 08:41:48 -0700 Subject: [Python-bugs-list] [Bug #110867] DCOracle select max() always returns integers (PR#289) Message-ID: <200008251541.IAA28177@delerium.i.sourceforge.net> Bug #110867, was updated on 2000-Aug-01 14:41 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: None Bug Group: 3rd Party Priority: 5 Summary: DCOracle select max() always returns integers (PR#289) Details: Jitterbug-Id: 289 Submitted-By: bchen@exelixis.com Date: Tue, 11 Apr 2000 18:52:54 -0400 (EDT) Version: 1.5.2 OS: SUN Solaris I am using DCOracle to retrieve the max and min values of an attribute from a database. The attribute contains floating point numbers. If I use select attr_name from table_name I got a list of floating point numbers. But if I call select max(attr_name) from table_name I always got integers. Can anyone help me figure out what's wrong? Thanks, Bin ==================================================================== Audit trail: Sat Jul 01 02:44:48 2000 fdrake moved from incoming to 3rdpartybug Follow-Ups: Date: 2000-Aug-25 07:41 By: jhylton Comment: Ken-- Can you forward this report to someone at DC and then close the Python bug? ------------------------------------------------------- Date: 2000-Aug-25 08:39 By: klm Comment: I've forwarded this to someone at digital creations, who will include it in the bug report mechanism here - for future reference, that's: http://classic.zope.org:8080/Collector (Bin, you may want to check the collector for bug reports related to the one you submitted.) ------------------------------------------------------- Date: 2000-Aug-25 08:41 By: klm Comment: Whoops - changing status to 'closed', since it's being deferred to the zope bug collector. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110867&group_id=5470 From noreply@sourceforge.net Fri Aug 25 16:44:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 08:44:12 -0700 Subject: [Python-bugs-list] [Bug #111860] file.writelines() crashes Message-ID: <200008251544.IAA06213@bush.i.sourceforge.net> Bug #111860, was updated on 2000-Aug-14 05:51 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 9 Summary: file.writelines() crashes Details: writelines() method causes GPF when sequence with arbitrary objects passed as argument. Unicode character are written to file as '\0'. Python 1.6b1, NT4.0 Follow-Ups: Date: 2000-Aug-25 08:44 By: jhylton Comment: >>> f = open('/dev/null', 'w') >>> l = ['1', 2] >>> class Foo: ... pass ... >>> l.append(Foo()) >>> >>> l ['1', 2, <__main__.Foo instance at 0x831fe2c>] >>> f.writelines(l) Segmentation fault (core dumped) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111860&group_id=5470 From noreply@sourceforge.net Fri Aug 25 16:56:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 08:56:42 -0700 Subject: [Python-bugs-list] [Bug #112113] Built-in exception class not found: UnboundLocalError. Message-ID: <200008251556.IAA28770@delerium.i.sourceforge.net> Bug #112113, was updated on 2000-Aug-16 12:12 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: Works For Me Bug Group: Platform-specific Priority: 7 Summary: Built-in exception class not found: UnboundLocalError. Details: I've just compiled Python-1.6b1 for QNX4.25 and QNX/Neutrino 2.1. The Neutrino port works ... but the QNX 4.25 port make problems: # ./python Built-in exception class not found: UnboundLocalError. Library mismatch? Fatal Python error: Standard exceptions could not be initialized. %1 19800 Abort ./python # The lookdict() call returns a NULL value in the init phase of python. Any tips for fixing that problem? Regards Armin Steinhoff Armin@Steinhoff.de Follow-Ups: Date: 2000-Aug-17 06:39 By: none Comment: QNX/Neutrino was compiled with -> GNU gcc QNX 4.25 with -> Watcom 10.6 Armin ------------------------------------------------------- Date: 2000-Aug-25 08:56 By: gvanrossum Comment: Closed. My suspicion is that this was caused by a spurious PYTHONPATH pointing to an old version of the library. The submittor can debug this by using "python -v". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112113&group_id=5470 From noreply@sourceforge.net Fri Aug 25 17:19:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 09:19:14 -0700 Subject: [Python-bugs-list] [Bug #110646] threads (PR#333) Message-ID: <200008251619.JAA07584@bush.i.sourceforge.net> Bug #110646, was updated on 2000-Jul-31 14:10 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Works For Me Bug Group: Platform-specific Priority: 5 Summary: threads (PR#333) Details: Jitterbug-Id: 333 Submitted-By: savichev@physik.uni-freiburg.de Date: Sat, 20 May 2000 17:36:46 -0400 (EDT) Version: 1.6a2 OS: IRIX64 './configure --with-threads' won't pass test_signal during 'make test'. './regrtest.py -v test_signal' # adds on in Makefile fixes the problem. test_threads goes through and test_signal on the compiled python completes also. './regrtest.py -v' mode shows that script = """ ( set %(x)s sleep 2 kill -5 %(pid)d sleep 2 kill -2 %(pid)d sleep 2 kill -3 %(pid)d ) can't be fully completed. ==================================================================== Audit trail: Mon May 22 17:29:29 2000 guido changed notes Tue Jul 11 08:29:18 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-25 09:19 By: sjoerd Comment: I have tested this on IRIX 6.5.2, both on IRIX and IRIX64 systems. I have tested both the latest version in the cnri-16-start branch and the main branch, and test_signal and test_thread both pass. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110646&group_id=5470 From noreply@sourceforge.net Fri Aug 25 17:24:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 09:24:17 -0700 Subject: [Python-bugs-list] [Bug #111860] file.writelines() crashes Message-ID: <200008251624.JAA07797@bush.i.sourceforge.net> Bug #111860, was updated on 2000-Aug-14 05:51 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: file.writelines() crashes Details: writelines() method causes GPF when sequence with arbitrary objects passed as argument. Unicode character are written to file as '\0'. Python 1.6b1, NT4.0 Follow-Ups: Date: 2000-Aug-25 08:44 By: jhylton Comment: >>> f = open('/dev/null', 'w') >>> l = ['1', 2] >>> class Foo: ... pass ... >>> l.append(Foo()) >>> >>> l ['1', 2, <__main__.Foo instance at 0x831fe2c>] >>> f.writelines(l) Segmentation fault (core dumped) ------------------------------------------------------- Date: 2000-Aug-25 09:24 By: jhylton Comment: Patch #101299 fixes the core dump for non-string objects. Not sure what the Unicode problem is, so assigning to MAL. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111860&group_id=5470 From noreply@sourceforge.net Fri Aug 25 18:00:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 10:00:30 -0700 Subject: [Python-bugs-list] [Bug #110713] strptime buffer overflow (PR#95) Message-ID: <200008251700.KAA09061@bush.i.sourceforge.net> Bug #110713, was updated on 2000-Jul-31 14:30 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: Wont Fix Bug Group: 3rd Party Priority: 7 Summary: strptime buffer overflow (PR#95) Details: Jitterbug-Id: 95 Submitted-By: bridge@gsnet.com Date: Tue, 5 Oct 1999 12:45:12 -0400 (EDT) Version: 1.5.2 OS: RedHat 5.2 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) ==================================================================== Audit trail: Wed Oct 06 11:12:55 1999 guido changed notes Wed Oct 06 11:12:55 1999 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-05 03:57 By: nowonder Comment: I cannot test this as I do not have RedHat 5.2. It works for me on SuSE Linux 6.4 both with 1.5.2 and the current CVS version. Somebody with a RedHat 5.2 system should check this out. ------------------------------------------------------- Date: 2000-Aug-25 10:00 By: jhylton Comment: This is not a Python bug. I can reproduce the core dump using straight C code. I'm running a RedHat 6.x system with glibc-2.1.2-11. I will investigate whether this is a known bug. There doesn't seem to be any way for Python to cope with this. /* Check for a bug in the local strptime, which manifests itself in Python as time.strptime("Oct 28 1999", "%b %d %X") */ #define _GNU_SOURCE #include main() { struct tm tm; char *result; memset((void *)&tm, '\0', sizeof(tm)); result = strptime("Oct 28 1999", "%b %d %X", &tm); } ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110713&group_id=5470 From noreply@sourceforge.net Fri Aug 25 18:12:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 10:12:54 -0700 Subject: [Python-bugs-list] [Bug #110713] strptime buffer overflow (PR#95) Message-ID: <200008251712.KAA09552@bush.i.sourceforge.net> Bug #110713, was updated on 2000-Jul-31 14:30 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: Wont Fix Bug Group: 3rd Party Priority: 7 Summary: strptime buffer overflow (PR#95) Details: Jitterbug-Id: 95 Submitted-By: bridge@gsnet.com Date: Tue, 5 Oct 1999 12:45:12 -0400 (EDT) Version: 1.5.2 OS: RedHat 5.2 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) ==================================================================== Audit trail: Wed Oct 06 11:12:55 1999 guido changed notes Wed Oct 06 11:12:55 1999 guido moved from incoming to platformbug Follow-Ups: Date: 2000-Aug-05 03:57 By: nowonder Comment: I cannot test this as I do not have RedHat 5.2. It works for me on SuSE Linux 6.4 both with 1.5.2 and the current CVS version. Somebody with a RedHat 5.2 system should check this out. ------------------------------------------------------- Date: 2000-Aug-25 10:00 By: jhylton Comment: This is not a Python bug. I can reproduce the core dump using straight C code. I'm running a RedHat 6.x system with glibc-2.1.2-11. I will investigate whether this is a known bug. There doesn't seem to be any way for Python to cope with this. /* Check for a bug in the local strptime, which manifests itself in Python as time.strptime("Oct 28 1999", "%b %d %X") */ #define _GNU_SOURCE #include main() { struct tm tm; char *result; memset((void *)&tm, '\0', sizeof(tm)); result = strptime("Oct 28 1999", "%b %d %X", &tm); } ------------------------------------------------------- Date: 2000-Aug-25 10:12 By: jhylton Comment: Verified that this bug is fixed with glibc 2.1.3. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110713&group_id=5470 From noreply@sourceforge.net Fri Aug 25 18:43:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 10:43:04 -0700 Subject: [Python-bugs-list] [Bug #110708] bug in time.sleep (PR#64) Message-ID: <200008251743.KAA10632@bush.i.sourceforge.net> Bug #110708, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Wont Fix Bug Group: Platform-specific Priority: 3 Summary: bug in time.sleep (PR#64) Details: Jitterbug-Id: 64 Submitted-By: ddula@atl.mediaone.net Date: Wed, 25 Aug 1999 14:02:51 -0400 (EDT) Version: 152c1 OS: Debian Alpha Linux (potato) 2.2.1 This is a interesting bug that seems to have started after I upgraded to debian potato from slink. It must be a library related bug but this report might help somebody troubleshoot. At first I thought it was a bug in threading because it prevented the solaris hack sleep from returning thus my thread.start() never returned. But further digging show that import time time.sleep(0.1) # will always hang on on this platform Work around is to always sleep at least one second - I will do some more looking at the time class when I get a chance. Dave Dula ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:15 1999 guido changed notes Follow-Ups: Date: 2000-Aug-25 07:03 By: jhylton Comment: I poked the original contributor. If he responds, I'll raise the priority. ------------------------------------------------------- Date: 2000-Aug-25 10:43 By: jhylton Comment: Dave Dula writes: My further digging show that it wasn't a bug with python really but the bug was that floor returned a very large number that caused sleep to 'hang' So I believed it either to be a kernel bug or a bug in libm but regardless I have just confirmed that on potato running 2.2.16 the problem no longer seems to exist so I think the bug can be closed out as a library bug that is now fixed ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110708&group_id=5470 From noreply@sourceforge.net Fri Aug 25 18:46:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 10:46:42 -0700 Subject: [Python-bugs-list] [Bug #110709] bug in time.sleep (PR#65) Message-ID: <200008251746.KAA10716@bush.i.sourceforge.net> Bug #110709, was updated on 2000-Jul-31 14:30 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in time.sleep (PR#65) Details: Jitterbug-Id: 65 Submitted-By: Dave Dula Date: Wed, 25 Aug 1999 20:18:25 -0400 (EDT) Version: None OS: None >>Full_Name: David Dula >>Version: 152c1 >>OS: Debian Alpha Linux (potato) 2.2.1 >>Submission from: client42207.atl.mediaone.net (24.88.42.207) >>his is a interesting bug that seems to have started after I upgraded to debian >>potato from slink. >>It must be a library related bug but this report might help somebody >>troubleshoot. >>At first I thought it was a bug in threading because it prevented the solaris >>hack sleep from returning >>thus my thread.start() never returned. >>But further digging show that >>import time >>time.sleep(0.1) # will always hang on on this platform >>Work around is to always sleep at least one second - I will do some more looking >>at the time class when I get a chance. This code shows it is the library that is broken. int main() { printf("%f\n",floor(0.100000)); } returns 36028797018963968.000000 So floor is broken. not a python bug sorry. I guess something is up with libm Dave Dula *-------------------------------------------------------------------------- Dave Dula ddula@atl.mediaone.net http://www.darkroom.cx Despite the cost of living, have you noticed how popular it remains? ==================================================================== Audit trail: Mon Aug 30 12:35:54 1999 guido moved from incoming to platformbug Mon Aug 30 12:36:23 1999 guido changed notes Follow-Ups: Date: 2000-Aug-25 10:46 By: jhylton Comment: Dave Dula writes: My further digging show that it wasn't a bug with python really but the bug was that floor returned a very large number that caused sleep to 'hang' So I believed it either to be a kernel bug or a bug in libm but regardless I have just confirmed that on potato running 2.2.16 the problem no longer seems to exist so I think the bug can be closed out as a library bug that is now fixed ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110709&group_id=5470 From noreply@sourceforge.net Fri Aug 25 18:47:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 10:47:52 -0700 Subject: [Python-bugs-list] [Bug #110861] time.sleep() and threading (PR#307) Message-ID: <200008251747.KAA10844@bush.i.sourceforge.net> Bug #110861, was updated on 2000-Aug-01 14:39 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Irreproducible Priority: 5 Summary: time.sleep() and threading (PR#307) Details: Jitterbug-Id: 307 Submitted-By: gpk@bell-labs.com Date: Fri, 28 Apr 2000 11:28:19 -0400 (EDT) Version: 1.5.2 OS: Solaris 2.6 sparc python .../test/test_thread.py shows that time.sleep() does not relinquish the processor. As one thread goes to sleep, another thread ought to start processing. That doesn't happen. Python was configured with --with-thread and compiler flags -mt and -D_REENTRANT. See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g EXAMPLE: hce* python test_thread.py creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 9.9 sec # goes to sleep here... task 1 done # 9.9 seconds later... task 5 will run for 4.1 sec # This should have started when task 1 slept. task 5 done task 7 will run for 9.9 sec task 7 done task 4 will run for 9.2 sec task 4 done task task 6 will run for 7.7 sec ==================================================================== Audit trail: Mon May 22 17:23:26 2000 guido changed notes Mon May 22 17:23:26 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:39 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] time.sleep() and threading (PR#307) Date: Wed, 03 May 2000 11:58:20 -0400 > python .../test/test_thread.py shows that time.sleep() > does not relinquish the processor. > As one thread goes to sleep, another thread ought > to start processing. That doesn't happen. > > Python was configured with --with-thread > and compiler flags -mt and -D_REENTRANT. > See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g > > EXAMPLE: > > hce* python test_thread.py > creating task 1 > creating task 2 > creating task 3 > creating task 4 > creating task 5 > creating task 6 > creating task 7 > creating task 8 > creating task 9 > creating task 10 > waiting for all tasks to complete > task 1 will run for 9.9 sec # goes to sleep here... > task 1 done # 9.9 seconds later... > task 5 will run for 4.1 sec # This should have started when task 1 slept. > task 5 done > task 7 will run for 9.9 sec > task 7 done > task 4 will run for 9.2 sec > task 4 done > task task 6 will run for 7.7 sec Hm... It works correctly for me on Solaris 7 compiled with gcc, using either Solaris threads or Posix threads. I wonder if this could have something to do with the compiler you are using? (Are you using the SunPro compiler?) There's not much I can do about this right now, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:39 By: none Comment: And wqent away when he upgraded to Py 1.6. ------------------------------------------------------- Date: 2000-Aug-25 10:47 By: jhylton Comment: Can you test this with Sun's compiler? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110861&group_id=5470 From noreply@sourceforge.net Fri Aug 25 18:50:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 10:50:09 -0700 Subject: [Python-bugs-list] [Bug #110863] Reference counting problem? (PR#338) Message-ID: <200008251750.KAA10876@bush.i.sourceforge.net> Bug #110863, was updated on 2000-Aug-01 14:39 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: None Bug Group: Not a Bug Priority: 1 Summary: Reference counting problem? (PR#338) Details: Jitterbug-Id: 338 Submitted-By: gpk@bell-labs.com Date: Wed, 24 May 2000 10:24:32 -0400 (EDT) Version: 1.6 as of 5/21/2000 OS: Solaris 2.6 Python 1.6 seems to have some kind of reference counting problem. The following function (in the midst of a large program) will crash with a nonsensical exception if I comment out the print statement. def _pull_types(d, nc): """Finds all the column definitions in the data file, that is, attributes in the form 'TTYPE#'. These attributes tell you what kind of data is in a specific column. It then builds an output dictionary that tells you what column contains any desired type of data.""" ts = type('') kl = d.keys() o = {} for k in kl: assert type(k)==ts, 'Key must be string' # comment out next line to crash: print "PULLTYPES(", k, ")", 'type(k)=', type(k) if len(k)>5 and k[:5] == 'TTYPE': col = string.atoi(k[5:]) if col>0 and col<=nc: o[d[k]] = col-1 return o Output with print statement in: ... PULLTYPES( HISTORY ) type(k)= PULLTYPES( _FILETYPE ) type(k)= PULLTYPES( I_NOISE ) type(k)= PULLTYPES( NAXIS2 ) type(k)= PULLTYPES( CDELT2 ) type(k)= PULLTYPES( CDELT1 ) type(k)= ... Output with print statement commented out: ... Traceback (most recent call last): File "/u/gpk/f0cls/bin/get_3_f0.sh", line 101, in ? pegg = get_f0(t + '/pegg.sd', pfile+'.pegg', t + '/pegg'); File "/u/gpk/f0cls/bin/get_3_f0.sh", line 83, in get_f0 return gpkimgclass.read(ttn + '.f0.dat') File "/home/gpk/lib/gpkimgclass.py", line 41, in read return gpk_img(hdr, data) File "/home/gpk/lib/gpkimgclass.py", line 69, in __init__ self.types = _pull_types(self.hdr, self.n[1]) File "/home/gpk/lib/gpkimgclass.py", line 23, in _pull_types if len(k)>5 and k[:5] == 'TTYPE': IndexError: list index out of range ... ==================================================================== Audit trail: Tue Jul 11 08:29:19 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:39 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Reference counting problem? (PR#338) Date: Thu, 25 May 2000 16:49:09 -0500 > Python 1.6 seems to have some kind of reference counting problem. > > The following function (in the midst of a large program) > will crash with a nonsensical exception if I comment out the > print statement. Without the whole program and its input data it's hard to debug this. Does your program use any nonstandard extension modules? That's where I'd start looking... A bug in core Python, while not impossible, is pretty unlikely. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:39 By: none Comment: From: Greg Kochanski Subject: Re: [Python-bugs-list] Reference counting problem? (PR#338) Date: Fri, 26 May 2000 11:36:51 -0400 Guido van Rossum wrote: > > > Python 1.6 seems to have some kind of reference counting problem. > > Without the whole program and its input data it's hard to debug this. > Does your program use any nonstandard extension modules? That's where > I'd start looking... It does. Some of the input data is a copy of a directory the nonstandard module produces. I'll look at the nonstandard module, and also see if I can isolate the problem to a reasonable-size chunk of code. ------------------------------------------------------- Date: 2000-Aug-25 07:31 By: jhylton Comment: Will close this one unless the original poster reponds. ------------------------------------------------------- Date: 2000-Aug-25 10:50 By: jhylton Comment: gpk attributes this to bug in his C extension. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110863&group_id=5470 From noreply@sourceforge.net Fri Aug 25 19:01:22 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 11:01:22 -0700 Subject: [Python-bugs-list] [Bug #111725] Response to bug 110619 Message-ID: <200008251801.LAA11303@bush.i.sourceforge.net> Bug #111725, was updated on 2000-Aug-11 15:30 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Response to bug 110619 Details: It probably should be documented somewhere that for urllib, proxies will not work in the environment variable http_proxy The code looks at http://usr:pwd@com:8080 and parses the pwd@com:8080 as a port number and fails. It also ignores the proxy details here. If the proxy details are put into the url, as argument to urlopen, they still don't work, although they are parsed correctly. I'm behind a firewall and this bugged me for some time, as I always received a http error code of 407. Afyter some research of the protocol, etc. I finally resolved it by modifying urllib in the open_http method and changed the line: if auth: h.putheader('Authorization',... to if auth: h.putheader('Proxy-Authorization',... and it worked! Needless to say, whatever aspect of the http protocol requires this to be 'Authorization' will of course now fail for my version of urllib, but at least the proxy part functions correctly. Sorry I can't give any better details as I am not an http guru, just fumbling along! Hope this helps. Cheers, Perry Faulkner (Perry.Faulkner@macquarie.com.au) Follow-Ups: Date: 2000-Aug-25 11:01 By: jhylton Comment: Looks like this is a documentation request. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111725&group_id=5470 From noreply@sourceforge.net Fri Aug 25 19:01:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 11:01:59 -0700 Subject: [Python-bugs-list] [Bug #110619] urllib.py fails with username/password proxies (PR#221) Message-ID: <200008251801.LAA11401@bush.i.sourceforge.net> Bug #110619, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urllib.py fails with username/password proxies (PR#221) Details: Jitterbug-Id: 221 Submitted-By: tarka@zip.com.au Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST) Version: 1.5.2 OS: Irix urllib.py fails to handle proxies with user and password information included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234 The following example ... import os, urllib os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234" f = urllib.urlopen('http://www.python.org') data = f.read() print data fails with the following errors : Traceback (innermost last): File "url.py", line 3, in ? f = urllib.urlopen('http://www.python.org') File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen return _urlopener.open(url) File "/var/share//lib/python1.5/urllib.py", line 157, in open return getattr(self, name)(url) File "/var/share//lib/python1.5/urllib.py", line 253, in open_http h = httplib.HTTP(host) File "/var/share//lib/python1.5/httplib.py", line 51, in __init__ if host: self.connect(host, port) File "/var/share//lib/python1.5/httplib.py", line 75, in connect raise socket.error, "nonnumeric port" IOError: [Errno socket error] nonnumeric port ==================================================================== Audit trail: Mon May 22 17:35:04 2000 guido moved from incoming to open For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110619&group_id=5470 From noreply@sourceforge.net Fri Aug 25 19:05:33 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 11:05:33 -0700 Subject: [Python-bugs-list] [Bug #111690] Bug: dictionary with >= 8192 keys not initialized correctly Message-ID: <200008251805.LAA11474@bush.i.sourceforge.net> Bug #111690, was updated on 2000-Aug-11 09:37 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: Bug: dictionary with >= 8192 keys not initialized correctly Details: Original posting to comp.lang.python: Save this to a file dictbug.py: print 'd1 = {' for i in xrange(8191): print str(i) + ': None,' print '}' print 'd2 = {' for i in xrange(8192): print str(i) + ': None,' print '}' print 'print len(d1)' print 'print len(d2)' Then run: python dictbug.py > tmp.py python tmp.py The output is: 8191 0 I tested this with: Python 1.5.2 (#1, Apr 28 2000, 11:50:55) [C] on osf1V5 Python 1.6b1 (#1, Aug 4 2000, 22:34:57) [C] on osf1V5 Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 If a dictionary is generated dynamically, e.g. by adding keys in a loop, there is no problem if there are >= 8192 keys. If there is an inherent problem with large dictionaries, it would be good if Python could at least raise an exception, e.g. SystemError. Ralf A reply to that posting: That's strange. I get a SyntaxError because the limit of subnodes for an expression was set to 8192: Python 2.0b1 (#2, Aug 7 2000, 10:06:00) [GCC 2.95.2 19991024 (release)] on linux2 File "dumm3.py", line 16386 8191: None, ^ SyntaxError: expression too long But then this probably was fixed after the 1.6b1 fork ... You should submit this to the bug tracker at sourceforge: http://sourceforge.net/bugs/?group_id=5470 Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-kamp.de N-7050 Trondheim http://schneider-kamp.de Follow-Ups: Date: 2000-Aug-25 11:05 By: jhylton Comment: believe cgw's long argument patch (more than 2**16 args) fixes this ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111690&group_id=5470 From noreply@sourceforge.net Fri Aug 25 20:51:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 12:51:17 -0700 Subject: [Python-bugs-list] [Bug #111586] 1.6b1: PythonPath Message-ID: <200008251951.MAA15425@bush.i.sourceforge.net> Bug #111586, was updated on 2000-Aug-10 09:52 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: 1.6b1: PythonPath Details: version: Python 1.6b1 os: Win2k i added an additional path to the PythonPath registry entry, but python ignores the additional path. (i used the windows installer, after deinstalling 1.5.2) Follow-Ups: Date: 2000-Aug-14 10:40 By: none Comment: i couldn't reproduce the problem with Windows ME (see also bug #111486). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111586&group_id=5470 From noreply@sourceforge.net Fri Aug 25 20:52:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 12:52:24 -0700 Subject: [Python-bugs-list] [Bug #111486] sys.argv in 1.6b1 Message-ID: <200008251952.MAA15529@bush.i.sourceforge.net> Bug #111486, was updated on 2000-Aug-09 07:32 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: sys.argv in 1.6b1 Details: version: 1.6b1 os: Win2k script > import sys > > for a in sys.argv: > print a called with > C:\Temp\site\bin>test 1 2 3 gives following result > C:\Temp\site\bin\test.py the parameters "1 2 3" are lost. Follow-Ups: Date: 2000-Aug-14 10:37 By: none Comment: i tried the same version with Windows ME, but couldn't reproduce the problem. but deinstalling 1.6b1 and reinstalling on Win2k didn't help. before installing 1.6b1, i had 1.5.2 running without any problems. i deinstalled 1.5.2 prior installation of 1.6b1. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111486&group_id=5470 From noreply@sourceforge.net Fri Aug 25 21:06:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 13:06:50 -0700 Subject: [Python-bugs-list] [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 Message-ID: <200008252006.NAA15967@bush.i.sourceforge.net> Bug #111319, was updated on 2000-Aug-07 16:29 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 6 Summary: Autoconfig breakdown with gnu libc-2.1.3 Details: Pythons config.h (which is included via Python.h) defines this on redhat-6.2: /* Define to `int' if doesn't define. */ #define socklen_t int The trouble is that gnu libc-2.1.3 does not define socklen_t in . It defines it in : /* Type for length arguments in socket calls. */ typedef unsigned int socklen_t; In this case, pythons definition causes a compilation failure which can be demonstrated by the following simple program: #include #include int main() { return 0; } My guess is that the autoconfig macros need to be updated to search as well. Mike Romberg (romberg@fsl.noaa.gov) Follow-Ups: Date: 2000-Aug-07 16:33 By: none Comment: This applies to python-1.6b1 ------------------------------------------------------- Date: 2000-Aug-25 13:06 By: jhylton Comment: I can not reproduce this on my system with glibc-2.1.3-15. Python compiles and runs cleanly; so does the test program in the bug report. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111319&group_id=5470 From noreply@sourceforge.net Fri Aug 25 21:37:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 13:37:52 -0700 Subject: [Python-bugs-list] [Bug #111204] 1.6b1 test_winreg tries importing wrong module Message-ID: <200008252037.NAA06689@delerium.i.sourceforge.net> Bug #111204, was updated on 2000-Aug-06 11:42 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 5 Summary: 1.6b1 test_winreg tries importing wrong module Details: test_winreg.py has an import winreg which fails since no such module exists. Changing to: import _winreg lets the test succeed fully. Should the module be build as winreg, or is it a bug in test_winreg.py? Alex Follow-Ups: Date: 2000-Aug-25 13:37 By: jhylton Comment: Fixed with version 1.4 of test_winreg.py ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111204&group_id=5470 From noreply@sourceforge.net Fri Aug 25 21:41:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 13:41:21 -0700 Subject: [Python-bugs-list] [Bug #111165] doc-string removal masked by PYTHONOPTIMIZE Message-ID: <200008252041.NAA06842@delerium.i.sourceforge.net> Bug #111165, was updated on 2000-Aug-05 15:21 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 7 Summary: doc-string removal masked by PYTHONOPTIMIZE Details: If Python is started with PYTHON -OO but the PYTHONOPTIMIZE environment variable is defined, then Py_OptimizeFlag is set back to 1 in pythonrun.c: if ((p = getenv("PYTHONOPTIMIZE")) && *p != '\0') Py_OptimizeFlag = 1; so doc-strings continue to be generated (compile.c line 2691): get_docstring(n) node *n; { /* Don't generate doc-strings if run with -OO */ if (Py_OptimizeFlag > 1) return NULL; For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111165&group_id=5470 From noreply@sourceforge.net Fri Aug 25 21:41:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 13:41:36 -0700 Subject: [Python-bugs-list] [Bug #111165] doc-string removal masked by PYTHONOPTIMIZE Message-ID: <200008252041.NAA06863@delerium.i.sourceforge.net> Bug #111165, was updated on 2000-Aug-05 15:21 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 7 Summary: doc-string removal masked by PYTHONOPTIMIZE Details: If Python is started with PYTHON -OO but the PYTHONOPTIMIZE environment variable is defined, then Py_OptimizeFlag is set back to 1 in pythonrun.c: if ((p = getenv("PYTHONOPTIMIZE")) && *p != '\0') Py_OptimizeFlag = 1; so doc-strings continue to be generated (compile.c line 2691): get_docstring(n) node *n; { /* Don't generate doc-strings if run with -OO */ if (Py_OptimizeFlag > 1) return NULL; For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111165&group_id=5470 From noreply@sourceforge.net Fri Aug 25 21:42:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 13:42:41 -0700 Subject: [Python-bugs-list] [Bug #111162] 1.6b1 test_math.py unconditionally tests math.rint Message-ID: <200008252042.NAA06882@delerium.i.sourceforge.net> Bug #111162, was updated on 2000-Aug-05 13:47 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: 1.6b1 test_math.py unconditionally tests math.rint Details: math.rint, according to the docs, only exists on certain platforms (where rint exists in the C libraries). However, test_math.py unconditionally tests it even on platforms where it does not exists, such as Windows; this makes a test failure for the 'math' test inevitable on those platforms. Follow-Ups: Date: 2000-Aug-25 13:42 By: jhylton Comment: Does this actually cause a test to fail? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111162&group_id=5470 From noreply@sourceforge.net Fri Aug 25 21:47:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 13:47:18 -0700 Subject: [Python-bugs-list] [Bug #110915] compiler core-dumps on illegal continue Message-ID: <200008252047.NAA07054@delerium.i.sourceforge.net> Bug #110915, was updated on 2000-Aug-02 05:13 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: compiler core-dumps on illegal continue Details: On my RedHat 6.2 system, the latest CVS version of python still dumps core on the following script: ------------------------------------------------- def gentheta(): while 1: try: continue finally: pass def genkappa(): if whatsmounted!='crystal': mountcrystal() while 1: if not inhibitmake: projtls.moveoutofway('kappa',dirok=1) os.mkdir('kappa') os.chdir('kappa') try: announce("Testing Kappa zero-point") # Use the detalign.vic produced by the dx calibration dal=os.path.join('..','dx','detalign.vic') if os.path.exists(dal): print "NOTE: Using detalign.vic from dx calibration" filecopy(dal,'detalign.vic') if not inhibitmake: status=os.system('calkappa make') else: status=os.system('calkappa') if status!=0: beeper.on() answer=command.question(root,'Calkappa Warnings',text='Calkappa issued some warnings and/or errors.\nPlease check what they are, and tell me what to do', strings=("Ignore them","Retry calkappa","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break if os.path.exists('instruct.txt'): beeper.on() answer=command.fixedfontquestion( root,'Kappa missetting needs correction', text=open('instruct.txt').read(), strings=("I have now done this","I'm ignoring this for now","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break else: # No instructions means no correction required break finally: os.chdir('..') ------------------------------------------- Any simplification in the second function makes the compiler report the "SyntaxError: continue not properly in loop" in line 4. Stack trace: ------------------------------------------- no203[140]~%3% gdb =python GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run x.py Starting program: /usr/local/nonius/bin/python x.py Program received signal SIGSEGV, Segmentation fault. PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 153 if (PyClass_Check(type)) { (gdb) where #0 PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 #1 0x8063901 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:672 #2 0x80638d6 in PyErr_Print () at pythonrun.c:663 #3 0x806368b in PyRun_SimpleFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:574 #4 0x806335d in PyRun_AnyFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:458 #5 0x80513c7 in Py_Main (argc=2, argv=0xbffff824) at main.c:271 #6 0x8050f56 in main (argc=2, argv=0xbffff824) at python.c:10 (gdb) The program is running. Exit anyway? (y or n) y Follow-Ups: Date: 2000-Aug-07 23:34 By: hooft Comment: Since today (compile.c 2.119) This no longer dumps core, but gives the new "SystemError: lost syntax error" error message. ------------------------------------------------------- Date: 2000-Aug-25 13:47 By: jhylton Comment: Is this bug now fixed? The most recent comment suggests it is. If so, please let me know and I'll close this report. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110915&group_id=5470 From noreply@sourceforge.net Fri Aug 25 21:48:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 13:48:24 -0700 Subject: [Python-bugs-list] [Bug #110870] Coredump in moduleobjectc.c:134 (PR#79) Message-ID: <200008252048.NAA07084@delerium.i.sourceforge.net> Bug #110870, was updated on 2000-Aug-01 14:42 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Invalid Bug Group: 3rd Party Priority: 5 Summary: Coredump in moduleobjectc.c:134 (PR#79) Details: Jitterbug-Id: 79 Submitted-By: ajung@sz-sb.de Date: Mon, 13 Sep 1999 07:29:09 -0400 (EDT) Version: 1.5.2 OS: Solaris 2.6/Sparc (ojs@bonnie:~/PROD/lib/site-python/ojs) 73 : !gdb gdb python core GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (sparc-sun-solaris2.4), Copyright 1996 Free Software Foundation, Inc... Core was generated by `python -v prod_descr.py'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libmp.so.2...done. Reading symbols from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1...done. Reading symbols from /ojs/home/ojs/PROD/lib/python1.5/site-packages/DateTime/mxDateTime/mxDateTime.so...done. #0 0x49220 in _PyModule_Clear (m=0xc76e4) at moduleobject.c:134 134 if (value != Py_None && PyString_Check(key)) { (gdb) bt #0 0x49220 in _PyModule_Clear (m=0xc76e4) at moduleobject.c:134 #1 0x29fe4 in PyImport_Cleanup () at import.c:308 #2 0x30d18 in Py_Finalize () at pythonrun.c:206 #3 0x21c8c in Py_Main (argc=3, argv=0xeffff964) at main.c:298 #4 0x216e4 in main (argc=3, argv=0xeffff964) at python.c:12 I get the traceback above from a small module that contains just 2 import statements. One module contains just the declaration of 2 classes and the second module contains some dicts,lists...nothing special. When I change the order of both import statements in the main script no core dump occurs. Any idea ? Andreas ==================================================================== Audit trail: Wed Sep 15 23:50:12 1999 guido changed notes Wed Sep 15 23:50:12 1999 guido moved from incoming to irreproducible Thu Sep 16 10:15:31 1999 guido changed notes Thu Sep 16 10:15:32 1999 guido moved from irreproducible to 3rdpartybug Follow-Ups: Date: 2000-Aug-01 14:42 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] Coredump in moduleobjectc.c:134 (PR#79) Date: Thu, 16 Sep 1999 10:04:18 -0400 > I was able to get more information. The problem might occur with the following code: > > * module.py* > > from prod_support import read_current_prodids > > PRODIDS = read_current_prodids() > > > * main.py * > > import module.py > > > When I run python on main.py I get the bus error. When I switch module.py to: > > import prod_support > PRODIDS = prod_support.read_current_prodids() > > everything is ok. The function read_current_prodids() uses DCOracle (Digicool/Zope). > I'm not sure if this causes the problem - I'll try to figure it out. Probably something in the prod_support module causes the problem. I'm quite sure the problem is not in Python itself, so the Python bugs list is not the place to report the bug. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:42 By: none Comment: Probably caused by DCOracle or other 3rd party extension. ------------------------------------------------------- Date: 2000-Aug-25 13:48 By: jhylton Comment: Guido says he is sure this is not a Python bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110870&group_id=5470 From noreply@sourceforge.net Fri Aug 25 22:00:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 14:00:50 -0700 Subject: [Python-bugs-list] [Bug #111165] doc-string removal masked by PYTHONOPTIMIZE Message-ID: <200008252100.OAA07629@delerium.i.sourceforge.net> Bug #111165, was updated on 2000-Aug-05 15:21 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Closed Resolution: None Bug Group: None Priority: 7 Summary: doc-string removal masked by PYTHONOPTIMIZE Details: If Python is started with PYTHON -OO but the PYTHONOPTIMIZE environment variable is defined, then Py_OptimizeFlag is set back to 1 in pythonrun.c: if ((p = getenv("PYTHONOPTIMIZE")) && *p != '\0') Py_OptimizeFlag = 1; so doc-strings continue to be generated (compile.c line 2691): get_docstring(n) node *n; { /* Don't generate doc-strings if run with -OO */ if (Py_OptimizeFlag > 1) return NULL; Follow-Ups: Date: 2000-Aug-25 14:00 By: lemburg Comment: Fix checked in. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111165&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:20:20 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:20:20 -0700 Subject: [Python-bugs-list] [Bug #110614] illegal argument type for built-in operation (PR#204) Message-ID: <200008252220.PAA10399@delerium.i.sourceforge.net> Bug #110614, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: illegal argument type for built-in operation (PR#204) Details: Jitterbug-Id: 204 Submitted-By: guido@python.org Date: Tue, 15 Feb 2000 14:24:27 -0500 (EST) Version: 1.5.2 OS: Solaris 2.7 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. ==================================================================== Audit trail: Wed Feb 23 21:31:39 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:06 By: none Comment: From: "Fred L. Drake, Jr." Subject: Re: [Python-bugs-list] illegal argument type for built-in operation (PR#204) Date: Tue, 15 Feb 2000 14:33:49 -0500 (EST) 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 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110614&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:27:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:27:09 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008252227.PAA10716@delerium.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 5 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- Date: 2000-Aug-10 11:48 By: gvanrossum Comment: No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } ------------------------------------------------------- Date: 2000-Aug-10 11:51 By: gvanrossum Comment: Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code. ------------------------------------------------------- Date: 2000-Aug-10 21:57 By: tim_one Comment: It's curious that in the change mail SF generated, leading indentation was *not* lost. This must be a browser display thing. Anyway, by eyeball the syntax checker has two bugs: 1. Infinite loop when looking at an exponent. x while (isdigit(*s)) digits++; should be x while (isdigit(*s)) {digits++; s++;) 2. Like atof, stops at an invalid character. Before the x return s; it should have, e.g., x while (ispace(*s)) ++s; x if (*s) return NULL; although I'm not sure what the assumptions are about the input to this function. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:27:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:27:54 -0700 Subject: [Python-bugs-list] [Bug #110625] trouble building under Solaris 7 (PR#260) Message-ID: <200008252227.PAA10735@delerium.i.sourceforge.net> Bug #110625, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: trouble building under Solaris 7 (PR#260) Details: Jitterbug-Id: 260 Submitted-By: lipman@helix.nih.gov Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST) Version: 1.5.2 OS: Solaris 7 106541-08 When I built Python on my machine: SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10 Python's internal symbols (for instance PySequence_Length) were not included in the dynamic symbol table of the python executable. This prevented the Numerical-15.2 extensions from importing properly. My machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker installed. I use the GNU linker, which is first in the $PATH under which Python was built. A workaround for this problem is to change the following line in Modules/Makefile.pre from LDFLAGS= to LDFLAGS= -export-dynamic This will only work for the GNU linker. ==================================================================== Audit trail: Mon May 22 17:39:59 2000 guido changed notes Mon May 22 17:39:59 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-06 14:25 By: twouters Comment: This might be fixed by newer autoconf ? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110625&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:28:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:28:08 -0700 Subject: [Python-bugs-list] [Bug #110614] illegal argument type for built-in operation (PR#204) Message-ID: <200008252228.PAA10739@delerium.i.sourceforge.net> Bug #110614, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Feature Request Priority: 3 Summary: illegal argument type for built-in operation (PR#204) Details: Jitterbug-Id: 204 Submitted-By: guido@python.org Date: Tue, 15 Feb 2000 14:24:27 -0500 (EST) Version: 1.5.2 OS: Solaris 2.7 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. ==================================================================== Audit trail: Wed Feb 23 21:31:39 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:06 By: none Comment: From: "Fred L. Drake, Jr." Subject: Re: [Python-bugs-list] illegal argument type for built-in operation (PR#204) Date: Tue, 15 Feb 2000 14:33:49 -0500 (EST) 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 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110614&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:29:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:29:47 -0700 Subject: [Python-bugs-list] [Bug #110924] support Unicode for Python source code Message-ID: <200008252229.PAA10767@delerium.i.sourceforge.net> Bug #110924, was updated on 2000-Aug-02 08:17 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Feature Request Priority: 1 Summary: support Unicode for Python source code Details: exec u"print 42" doesn't work. Follow-Ups: Date: 2000-Aug-09 02:35 By: effbot Comment: python doesn't support 16-bit source code -- so what exactly do you want exec to do? ------------------------------------------------------- Date: 2000-Aug-17 05:17 By: none Comment: That's exactly my point. Python should support Unicode everywhere, in __str__ and __repr__, exec and eval, in open(), as a format for the source code (which would result in all variable names to be Unicode)... Currenly working with Unicode (e.g. for XML) is a mess, because it's supported nowhere. exec "a='ü'" seems to work and seems to treat the string as iso-8859-1 (or not at all) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110924&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:35:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:35:53 -0700 Subject: [Python-bugs-list] [Bug #110702] closing a popen file descriptor (PR#33) Message-ID: <200008252235.PAA11115@delerium.i.sourceforge.net> Bug #110702, was updated on 2000-Jul-31 14:29 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: closing a popen file descriptor (PR#33) Details: Jitterbug-Id: 33 Submitted-By: laik@cs.stanford.edu Date: Tue, 20 Jul 1999 14:00:11 -0400 (EDT) Version: 1.5.2 OS: Linux 2.2.10 I can't close a pipe's file descriptor without an error: >>> import os >>> p1 = os.popen("cat dummy1", "r") >>> p2 = os.popen("cat dummy2", "r") >>> p1.close() Traceback (innermost last): File "", line 1, in ? IOError: (0, 'Error') It only happens if I do two or more popens. If I try to close any file descriptor but the last one I opened, I get this mysterious IOError. It happens regardless of the order I try to close the descriptors. ==================================================================== Audit trail: Sat Jul 24 17:02:54 1999 guido sent reply 1 Sat Jul 24 17:03:22 1999 guido changed notes Sat Jul 24 17:03:22 1999 guido moved from incoming to open Sat Jul 24 17:05:25 1999 guido moved from open to platformbug Follow-Ups: Date: 2000-Aug-01 14:03 By: none Comment: From: Guido van Rossum Subject: Re: closing a popen file descriptor (PR#33) Date: Sat Jul 24 17:02:54 1999 > Full_Name: Kevin Lai > Version: 1.5.2 > OS: Linux 2.2.10 > Submission from: (NULL) (192.25.214.6) > > > I can't close a pipe's file descriptor without an error: > >>>> import os >>>> p1 = os.popen("cat dummy1", "r") >>>> p2 = os.popen("cat dummy2", "r") >>>> p1.close() > Traceback (innermost last): > File "", line 1, in ? > IOError: (0, 'Error') > > It only happens if I do two or more popens. If I try to close any file > descriptor > but the last one I opened, I get this mysterious IOError. It happens regardless > of the order I try to close the descriptors. Kevin, this works on other platforms I can try (Solaris 2.6, linux 2.0.34). One possibility is that the C library in the Linux version you are using has changed; the IOError means that its pclose() returns an error indicator. The (0, 'Error') message means that pclose() didn't set the errno variable. It could be a bug in the Linux C library, or a change in interface that requires Python to interpret the error return differently. Can you help us discover which is the case? Does the man page for pclose() say anything about this? Does this fail in an equivalent C program? --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: From: laik@tnt.Stanford.EDU Subject: Re: closing a popen file descriptor (PR#33) Date: Tue, 27 Jul 1999 01:41:15 -0700 Guido, Thanks for your quick reply. As far as I can tell, the man page for pclose() doesn't mention any API changes. I have included the popen() and wait4() man pages for the system I am using (PII 300, Linux 2.2.10, glibc 2.1.1). I have written a short C program which tries to exercise the bug. On my system, it gives these results: [laik@nebraska]~>gcc popen.c [laik@nebraska]~>a.out pclose(p1): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 pclose(p2): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 pclose(p3): 0, WIFEXITED: 1, WEXITSTATUS:0, WIFSIGNALED:0 On a Linux 2.0.33, glibc 2.0.7 system, it gives the same results. However, my system exhibits the problem under Python, while the other does not. I conclude that my C program doesn't mimic the Python program well enough to trigger the bug, but I don't know how to fix that. #include #define _USE_BSD #include #include #include main() { FILE *p1, *p2, *p3; int pc1, pc2, pc3; p1 = popen("ls", "r"); p2 = popen("ls", "r"); p3 = popen("ls", "r"); sleep(1); pc1 = pclose(p1); printf("pclose(p1): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc1, WIFEXITED(pc1), WEXITSTATUS(pc1), WIFSIGNALED(pc1)); pc2 = pclose(p2); printf("pclose(p2): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc1, WIFEXITED(pc2), WEXITSTATUS(pc2), WIFSIGNALED(pc2)); pc3 = pclose(p3); printf("pclose(p3): %d, WIFEXITED: %d, WEXITSTATUS:%d, WIFSIGNALED:%d\n", pc3, WIFEXITED(pc3), WEXITSTATUS(pc3), WIFSIGNALED(pc3)); } POPEN(3) Linux Programmer's Manual POPEN(3) NAME popen, pclose - process I/O SYNOPSIS #include FILE *popen(const char *command, const char *type); int pclose(FILE *stream); DESCRIPTION The popen() function opens a process by creating a pipe, forking, and invoking the shell. Since a pipe is by defi- nition unidirectional, the type argument may specify only reading or writing, not both; the resulting stream is cor- respondingly read-only or write-only. The command argument is a pointer to a null-terminated string containing a shell command line. This command is passed to /bin/sh using the -c flag; interpretation, if any, is performed by the shell. The mode argument is a pointer to a null-terminated string which must be either `r' for reading or `w' for writing. The return value from popen() is a normal standard I/O stream in all respects save that it must be closed with pclose() rather than fclose(). Writing to such a stream writes to the standard input of the command; the command's standard output is the same as that of the process that called popen(), unless this is altered by the command itself. Conversely, reading from a ``popened'' stream reads the command's standard output, and the command's standard input is the same as that of the process that called popen. Note that output popen streams are fully buffered by default. The pclose function waits for the associated process to terminate and returns the exit status of the command as returned by wait4. RETURN VALUE The popen function returns NULL if the fork(2) or pipe(2) calls fail, or if it cannot allocate memory. The pclose function returns -1 if wait4 returns an error, or some other error is detected. ERRORS The popen function does not set errno if memory allocation fails. If the underlying fork() or pipe() fails, errno is set appropriately. If the mode argument is invalid, and this condition is detected, errno is set to EINVAL. If pclose() cannot obtain the child status, errno is set to ECHILD. CONFORMING TO POSIX.2 BUGS Since the standard input of a command opened for reading shares its seek offset with the process that called popen(), if the original process has done a buffered read, the command's input position may not be as expected. Sim- ilarly, the output from a command opened for writing may become intermingled with that of the original process. The latter can be avoided by calling fflush(3) before popen. Failure to execute the shell is indistinguishable from the shell's failure to execute command, or an immediate exit of the command. The only hint is an exit status of 127. HISTORY A popen() and a pclose() function appeared in Version 7 AT&T UNIX. SEE ALSO fork(2), sh(1), pipe(2), wait4(2), fflush(3), fclose(3), fopen(3), stdio(3), system(3). BSD MANPAGE 7 May 1998 1 WAIT4(2) Linux Programmer's Manual WAIT4(2) NAME wait3, wait4 - wait for process termination, BSD style SYNOPSIS #define _USE_BSD #include #include #include pid_t wait3(int *status, int options, struct rusage *rusage) pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage) DESCRIPTION The wait3 function suspends execution of the current pro- cess until a child has exited, or until a signal is deliv- ered whose action is to terminate the current process or to call a signal handling function. If a child has already exited by the time of the call (a so-called "zom- bie" process), the function returns immediately. Any sys- tem resources used by the child are freed. The wait4 function suspends execution of the current pro- cess until a child as specified by the pid argument has exited, or until a signal is delivered whose action is to terminate the current process or to call a signal handling function. If a child as requested by pid has already exited by the time of the call (a so-called "zombie" pro- cess), the function returns immediately. Any system resources used by the child are freed. The value of pid can be one of: < -1 which means to wait for any child process whose process group ID is equal to the absolute value of pid. -1 which means to wait for any child process; this is equivalent to calling wait3. 0 which means to wait for any child process whose process group ID is equal to that of the calling process. > 0 which means to wait for the child whose process ID is equal to the value of pid. The value of options is a bitwise OR of zero or more of the following constants: WNOHANG which means to return immediately if no child is there to be waited for. WUNTRACED which means to also return for children which are stopped, and whose status has not been reported. If status is not NULL, wait3 or wait4 store status infor- mation in the location pointed to by status. This status can be evaluated with the following macros (these macros take the stat buffer (an int) as an argument -- not a pointer to the buffer!): WIFEXITED(status) is non-zero if the child exited normally. WEXITSTATUS(status) evaluates to the least significant eight bits of the return code of the child which terminated, which may have been set as the argument to a call to exit() or as the argument for a return state- ment in the main program. This macro can only be evaluated if WIFEXITED returned non-zero. WIFSIGNALED(status) returns true if the child process exited because of a signal which was not caught. WTERMSIG(status) returns the number of the signal that caused the child process to terminate. This macro can only be evaluated if WIFSIGNALED returned non-zero. WIFSTOPPED(status) returns true if the child process which caused the return is currently stopped; this is only possible if the call was done using WUNTRACED. WSTOPSIG(status) returns the number of the signal which caused the child to stop. This macro can only be evaluated if WIFSTOPPED returned non-zero. If rusage is not NULL, the struct rusage as defined in it points to will be filled with accounting information. See getrusage(2) for details. RETURN VALUE The process ID of the child which exited, -1 on error (in particular, when no unwaited-for child processes of the specified kind exist) or zero if WNOHANG was used and no child was available yet. In the latter two cases errno will be set appropriately. ERRORS ECHILD No unwaited-for child process as specified does exist. ERESTARTSYS if WNOHANG was not set and an unblocked signal or a SIGCHLD was caught. This error is returned by the system call. The library interface is not allowed to return ERESTARTSYS, but will return EINTR. CONFORMING TO SVr4, POSIX.1 SEE ALSO signal(2), getrusage(2), wait(2), signal(7) Linux 23 June 1997 1 ------------------------------------------------------- Date: 2000-Aug-01 14:03 By: none Comment: Perhaps a bug or interface change in Linux popen()? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110702&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:36:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:36:42 -0700 Subject: [Python-bugs-list] [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 Message-ID: <200008252236.PAA11134@delerium.i.sourceforge.net> Bug #111319, was updated on 2000-Aug-07 16:29 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: None Bug Group: Platform-specific Priority: 6 Summary: Autoconfig breakdown with gnu libc-2.1.3 Details: Pythons config.h (which is included via Python.h) defines this on redhat-6.2: /* Define to `int' if doesn't define. */ #define socklen_t int The trouble is that gnu libc-2.1.3 does not define socklen_t in . It defines it in : /* Type for length arguments in socket calls. */ typedef unsigned int socklen_t; In this case, pythons definition causes a compilation failure which can be demonstrated by the following simple program: #include #include int main() { return 0; } My guess is that the autoconfig macros need to be updated to search as well. Mike Romberg (romberg@fsl.noaa.gov) Follow-Ups: Date: 2000-Aug-07 16:33 By: none Comment: This applies to python-1.6b1 ------------------------------------------------------- Date: 2000-Aug-25 13:06 By: jhylton Comment: I can not reproduce this on my system with glibc-2.1.3-15. Python compiles and runs cleanly; so does the test program in the bug report. ------------------------------------------------------- Date: 2000-Aug-25 15:36 By: jhylton Comment: Original submittors confirms that this is fixed. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111319&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:39:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:39:56 -0700 Subject: [Python-bugs-list] [Bug #111162] 1.6b1 test_math.py unconditionally tests math.rint Message-ID: <200008252239.PAA21605@bush.i.sourceforge.net> Bug #111162, was updated on 2000-Aug-05 13:47 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 7 Summary: 1.6b1 test_math.py unconditionally tests math.rint Details: math.rint, according to the docs, only exists on certain platforms (where rint exists in the C libraries). However, test_math.py unconditionally tests it even on platforms where it does not exists, such as Windows; this makes a test failure for the 'math' test inevitable on those platforms. Follow-Ups: Date: 2000-Aug-25 13:42 By: jhylton Comment: Does this actually cause a test to fail? ------------------------------------------------------- Date: 2000-Aug-25 15:39 By: tim_one Comment: This was true in 1.6b1, but Guido removed math.rint entirely for 1.6 final. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111162&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:45:52 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:45:52 -0700 Subject: [Python-bugs-list] [Bug #110915] compiler core-dumps on illegal continue Message-ID: <200008252245.PAA21797@bush.i.sourceforge.net> Bug #110915, was updated on 2000-Aug-02 05:13 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: compiler core-dumps on illegal continue Details: On my RedHat 6.2 system, the latest CVS version of python still dumps core on the following script: ------------------------------------------------- def gentheta(): while 1: try: continue finally: pass def genkappa(): if whatsmounted!='crystal': mountcrystal() while 1: if not inhibitmake: projtls.moveoutofway('kappa',dirok=1) os.mkdir('kappa') os.chdir('kappa') try: announce("Testing Kappa zero-point") # Use the detalign.vic produced by the dx calibration dal=os.path.join('..','dx','detalign.vic') if os.path.exists(dal): print "NOTE: Using detalign.vic from dx calibration" filecopy(dal,'detalign.vic') if not inhibitmake: status=os.system('calkappa make') else: status=os.system('calkappa') if status!=0: beeper.on() answer=command.question(root,'Calkappa Warnings',text='Calkappa issued some warnings and/or errors.\nPlease check what they are, and tell me what to do', strings=("Ignore them","Retry calkappa","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break if os.path.exists('instruct.txt'): beeper.on() answer=command.fixedfontquestion( root,'Kappa missetting needs correction', text=open('instruct.txt').read(), strings=("I have now done this","I'm ignoring this for now","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break else: # No instructions means no correction required break finally: os.chdir('..') ------------------------------------------- Any simplification in the second function makes the compiler report the "SyntaxError: continue not properly in loop" in line 4. Stack trace: ------------------------------------------- no203[140]~%3% gdb =python GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run x.py Starting program: /usr/local/nonius/bin/python x.py Program received signal SIGSEGV, Segmentation fault. PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 153 if (PyClass_Check(type)) { (gdb) where #0 PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 #1 0x8063901 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:672 #2 0x80638d6 in PyErr_Print () at pythonrun.c:663 #3 0x806368b in PyRun_SimpleFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:574 #4 0x806335d in PyRun_AnyFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:458 #5 0x80513c7 in Py_Main (argc=2, argv=0xbffff824) at main.c:271 #6 0x8050f56 in main (argc=2, argv=0xbffff824) at python.c:10 (gdb) The program is running. Exit anyway? (y or n) y Follow-Ups: Date: 2000-Aug-07 23:34 By: hooft Comment: Since today (compile.c 2.119) This no longer dumps core, but gives the new "SystemError: lost syntax error" error message. ------------------------------------------------------- Date: 2000-Aug-25 13:47 By: jhylton Comment: Is this bug now fixed? The most recent comment suggests it is. If so, please let me know and I'll close this report. ------------------------------------------------------- Date: 2000-Aug-25 15:45 By: tim_one Comment: Well, while raising SystemError is friendlier than a core dump, at heart they're both ways to spell "the compiler is *really* confused" -- we shouldn't ever raise SystemError. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110915&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:50:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:50:30 -0700 Subject: [Python-bugs-list] [Bug #111860] file.writelines() crashes Message-ID: <200008252250.PAA21975@bush.i.sourceforge.net> Bug #111860, was updated on 2000-Aug-14 05:51 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 7 Summary: file.writelines() crashes Details: writelines() method causes GPF when sequence with arbitrary objects passed as argument. Unicode character are written to file as '\0'. Python 1.6b1, NT4.0 Follow-Ups: Date: 2000-Aug-25 08:44 By: jhylton Comment: >>> f = open('/dev/null', 'w') >>> l = ['1', 2] >>> class Foo: ... pass ... >>> l.append(Foo()) >>> >>> l ['1', 2, <__main__.Foo instance at 0x831fe2c>] >>> f.writelines(l) Segmentation fault (core dumped) ------------------------------------------------------- Date: 2000-Aug-25 09:24 By: jhylton Comment: Patch #101299 fixes the core dump for non-string objects. Not sure what the Unicode problem is, so assigning to MAL. ------------------------------------------------------- Date: 2000-Aug-25 15:50 By: lemburg Comment: Fix checked in. file.writelines() now works just like file.write()... Unicode will get written using the default encoding. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111860&group_id=5470 From noreply@sourceforge.net Fri Aug 25 23:55:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 15:55:42 -0700 Subject: [Python-bugs-list] [Bug #110915] compiler core-dumps on illegal continue Message-ID: <200008252255.PAA22133@bush.i.sourceforge.net> Bug #110915, was updated on 2000-Aug-02 05:13 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: compiler core-dumps on illegal continue Details: On my RedHat 6.2 system, the latest CVS version of python still dumps core on the following script: ------------------------------------------------- def gentheta(): while 1: try: continue finally: pass def genkappa(): if whatsmounted!='crystal': mountcrystal() while 1: if not inhibitmake: projtls.moveoutofway('kappa',dirok=1) os.mkdir('kappa') os.chdir('kappa') try: announce("Testing Kappa zero-point") # Use the detalign.vic produced by the dx calibration dal=os.path.join('..','dx','detalign.vic') if os.path.exists(dal): print "NOTE: Using detalign.vic from dx calibration" filecopy(dal,'detalign.vic') if not inhibitmake: status=os.system('calkappa make') else: status=os.system('calkappa') if status!=0: beeper.on() answer=command.question(root,'Calkappa Warnings',text='Calkappa issued some warnings and/or errors.\nPlease check what they are, and tell me what to do', strings=("Ignore them","Retry calkappa","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break if os.path.exists('instruct.txt'): beeper.on() answer=command.fixedfontquestion( root,'Kappa missetting needs correction', text=open('instruct.txt').read(), strings=("I have now done this","I'm ignoring this for now","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break else: # No instructions means no correction required break finally: os.chdir('..') ------------------------------------------- Any simplification in the second function makes the compiler report the "SyntaxError: continue not properly in loop" in line 4. Stack trace: ------------------------------------------- no203[140]~%3% gdb =python GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run x.py Starting program: /usr/local/nonius/bin/python x.py Program received signal SIGSEGV, Segmentation fault. PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 153 if (PyClass_Check(type)) { (gdb) where #0 PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 #1 0x8063901 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:672 #2 0x80638d6 in PyErr_Print () at pythonrun.c:663 #3 0x806368b in PyRun_SimpleFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:574 #4 0x806335d in PyRun_AnyFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:458 #5 0x80513c7 in Py_Main (argc=2, argv=0xbffff824) at main.c:271 #6 0x8050f56 in main (argc=2, argv=0xbffff824) at python.c:10 (gdb) The program is running. Exit anyway? (y or n) y Follow-Ups: Date: 2000-Aug-07 23:34 By: hooft Comment: Since today (compile.c 2.119) This no longer dumps core, but gives the new "SystemError: lost syntax error" error message. ------------------------------------------------------- Date: 2000-Aug-25 13:47 By: jhylton Comment: Is this bug now fixed? The most recent comment suggests it is. If so, please let me know and I'll close this report. ------------------------------------------------------- Date: 2000-Aug-25 15:45 By: tim_one Comment: Well, while raising SystemError is friendlier than a core dump, at heart they're both ways to spell "the compiler is *really* confused" -- we shouldn't ever raise SystemError. ------------------------------------------------------- Date: 2000-Aug-25 15:55 By: tim_one Comment: Note comment from compile.c: /* This could happen if someone called PyErr_Clear() after * an error was reported above. That's not supposed to * happen, but I just plugged one case and I'm not sure * there can't be others. In that case, raise SystemError * so that at least it gets reported instead dumping core. */ PyErr_SetString(PyExc_SystemError, "lost syntax error"); So we got an internal error going here all right. Can't reproduce under Windows, though. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110915&group_id=5470 From noreply@sourceforge.net Sat Aug 26 01:15:00 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 17:15:00 -0700 Subject: [Python-bugs-list] [Bug #111586] 1.6b1: PythonPath Message-ID: <200008260015.RAA24656@bush.i.sourceforge.net> Bug #111586, was updated on 2000-Aug-10 09:52 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Closed Resolution: Works For Me Bug Group: Platform-specific Priority: 7 Summary: 1.6b1: PythonPath Details: version: Python 1.6b1 os: Win2k i added an additional path to the PythonPath registry entry, but python ignores the additional path. (i used the windows installer, after deinstalling 1.5.2) Follow-Ups: Date: 2000-Aug-14 10:40 By: none Comment: i couldn't reproduce the problem with Windows ME (see also bug #111486). ------------------------------------------------------- Date: 2000-Aug-25 17:15 By: mhammond Comment: Can only assume operator error - I use this feature personally, win32all uses it, and ActivePython uses it. It works! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111586&group_id=5470 From noreply@sourceforge.net Sat Aug 26 01:25:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 17:25:42 -0700 Subject: [Python-bugs-list] [Bug #112759] open('file').read() can not read entire binary file Message-ID: <200008260025.RAA24953@bush.i.sourceforge.net> Bug #112759, was updated on 2000-Aug-25 17:25 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: open('file').read() can not read entire binary file Details: I have a binary data file "myfile.dat" with file length 26360 bytes. when doing >>>f=open("myfile.dat") >>>data = f.read() >>>len(data) 3325 This is repeatable on most of (little) big binary files. I guess it is because some binary pattern in the file interrupts the reading. I tried with JPython, it works fine there. Probably that is using java's file-IO Jianchi Wei For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112759&group_id=5470 From noreply@sourceforge.net Sat Aug 26 01:38:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 17:38:02 -0700 Subject: [Python-bugs-list] [Bug #112760] python can not read binary file fully Message-ID: <200008260038.RAA25389@bush.i.sourceforge.net> Bug #112760, was updated on 2000-Aug-25 17:38 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 5 Summary: python can not read binary file fully Details: a binary file (named, say:"mybifile.dat") with length of 26360 (bytes) can not be read fully: >>>f=open("mybifile.dat") >>>data=f.read() >>>len(data) 3325 The reading seems to be interrupted by the binary pattern in the file. I tried the same with JPython, it works there. I guess it uses java's file-IO. Jianchi For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112760&group_id=5470 From noreply@sourceforge.net Sat Aug 26 02:20:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 18:20:15 -0700 Subject: [Python-bugs-list] [Bug #112760] python can not read binary file fully Message-ID: <200008260120.SAA16666@delerium.i.sourceforge.net> Bug #112760, was updated on 2000-Aug-25 17:38 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Invalid Bug Group: None Priority: 5 Summary: python can not read binary file fully Details: a binary file (named, say:"mybifile.dat") with length of 26360 (bytes) can not be read fully: >>>f=open("mybifile.dat") >>>data=f.read() >>>len(data) 3325 The reading seems to be interrupted by the binary pattern in the file. I tried the same with JPython, it works there. I guess it uses java's file-IO. Jianchi Follow-Ups: Date: 2000-Aug-25 18:20 By: effbot Comment: http://www.python.org/doc/current/lib/built-in-funcs.html => open => "Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files" or in other words, change open("mybifile.dat") to open("mybifile.dat", "rb") (this also falls into the "don't you think someone would have noticed already" category ;-) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112760&group_id=5470 From noreply@sourceforge.net Sat Aug 26 02:21:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 18:21:25 -0700 Subject: [Python-bugs-list] [Bug #112759] open('file').read() can not read entire binary file Message-ID: <200008260121.SAA16777@delerium.i.sourceforge.net> Bug #112759, was updated on 2000-Aug-25 17:25 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Duplicate Bug Group: None Priority: 5 Summary: open('file').read() can not read entire binary file Details: I have a binary data file "myfile.dat" with file length 26360 bytes. when doing >>>f=open("myfile.dat") >>>data = f.read() >>>len(data) 3325 This is repeatable on most of (little) big binary files. I guess it is because some binary pattern in the file interrupts the reading. I tried with JPython, it works fine there. Probably that is using java's file-IO Jianchi Wei Follow-Ups: Date: 2000-Aug-25 18:21 By: effbot Comment: http://www.python.org/doc/current/lib/built-in-funcs.html => open => "Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files" or in other words, change open("myfile.dat") to open("myfile.dat", "rb") (this also falls into the "don't you think someone would have noticed already" category ;-) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112759&group_id=5470 From noreply@sourceforge.net Sat Aug 26 02:30:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 25 Aug 2000 18:30:46 -0700 Subject: [Python-bugs-list] [Bug #112759] open('file').read() can not read entire binary file Message-ID: <200008260130.SAA17102@delerium.i.sourceforge.net> Bug #112759, was updated on 2000-Aug-25 17:25 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Duplicate Bug Group: Not a Bug Priority: 5 Summary: open('file').read() can not read entire binary file Details: I have a binary data file "myfile.dat" with file length 26360 bytes. when doing >>>f=open("myfile.dat") >>>data = f.read() >>>len(data) 3325 This is repeatable on most of (little) big binary files. I guess it is because some binary pattern in the file interrupts the reading. I tried with JPython, it works fine there. Probably that is using java's file-IO Jianchi Wei Follow-Ups: Date: 2000-Aug-25 18:21 By: effbot Comment: http://www.python.org/doc/current/lib/built-in-funcs.html => open => "Append 'b' to the mode to open the file in binary mode, on systems that differentiate between binary and text files" or in other words, change open("myfile.dat") to open("myfile.dat", "rb") (this also falls into the "don't you think someone would have noticed already" category ;-) ------------------------------------------------------- Date: 2000-Aug-25 18:30 By: tim_one Comment: Just changed group to "Not a Bug". ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112759&group_id=5470 From noreply@sourceforge.net Sat Aug 26 09:39:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 01:39:47 -0700 Subject: [Python-bugs-list] [Bug #112786] Build under Cygwin fails Message-ID: <200008260839.BAA07210@bush.i.sourceforge.net> Bug #112786, was updated on 2000-Aug-26 01:39 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: Build under Cygwin fails Details: Py1.6b1 ======== 1) socketmodule.c -- looks for netinet/tcp.h, which does not exist on cygwin. 2) gcc python.o \ ../libpython1.6.a -lm -o python python.o: In function `main': /usr/local/bin/Python-1.6b1/Modules/python.c:12: undefined reference to `Py_Main For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112786&group_id=5470 From noreply@sourceforge.net Sat Aug 26 16:04:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 26 Aug 2000 08:04:58 -0700 Subject: [Python-bugs-list] [Bug #112265] Impossible to get Win32 default font encoding in widgets Message-ID: <200008261504.IAA09666@delerium.i.sourceforge.net> Bug #112265, was updated on 2000-Aug-18 13:37 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: Later Bug Group: Platform-specific Priority: 6 Summary: Impossible to get Win32 default font encoding in widgets Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly. As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it? Follow-Ups: Date: 2000-Aug-26 08:04 By: effbot Comment: this is really a "how do I", rather than a bug report ;-) ::: In 1.6 and beyond, Python's default 8-bit encoding is plain ASCII. this encoding is only used when you're using 8-bit strings in "unicode contexts" -- for example, if you compare an 8-bit string to a unicode string, or pass it to a subsystem designed to use unicode strings. If you pass an 8-bit string containing characters outside the ASCII range to a function expecting a unicode string, the result is undefined (it's usually results in an exception, but some subsystems may have other ideas). Finally, Tkinter now supports Unicode. In fact, it assumes that all strings passed to it are Unicode. When using 8-bit strings, it's only safe to use plain ASCII. Tkinter currently doesn't raise exceptions for 8-bit strings with non-ASCII characters, but it probably should. Otherwise, Tk will attempt to parse the string as an UTF-8 string, and if that fails, it assumes ISO-8859-1. ::: Anyway, to write portable code using characters outside the ASCII character set, you should use unicode strings. in your case, you can use: s = unicode("", "cp1250") to get the platform's default encoding, you can do: import locale language, encoding = locale.getdefaultlocale() where encoding should be cp1250 on your box. ::: The reason this work under Tcl/Tk is that Tcl assumes that your source code uses the platform's default encoding, and converts things to Unicode (not necessarily UTF-8) for you under the hood. Python 2.1 will hopefully support *explicit* source encodings, but 1.6/2.0 doesn't. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470 From noreply@sourceforge.net Sun Aug 27 19:38:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 11:38:36 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008271838.LAA07873@bush.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 5 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- Date: 2000-Aug-10 11:48 By: gvanrossum Comment: No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } ------------------------------------------------------- Date: 2000-Aug-10 11:51 By: gvanrossum Comment: Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code. ------------------------------------------------------- Date: 2000-Aug-10 21:57 By: tim_one Comment: It's curious that in the change mail SF generated, leading indentation was *not* lost. This must be a browser display thing. Anyway, by eyeball the syntax checker has two bugs: 1. Infinite loop when looking at an exponent. x while (isdigit(*s)) digits++; should be x while (isdigit(*s)) {digits++; s++;) 2. Like atof, stops at an invalid character. Before the x return s; it should have, e.g., x while (ispace(*s)) ++s; x if (*s) return NULL; although I'm not sure what the assumptions are about the input to this function. ------------------------------------------------------- Date: 2000-Aug-27 11:38 By: gvanrossum Comment: I'm mailing Tim a fixed version of floatsyntax(). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Sun Aug 27 19:40:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 11:40:14 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008271840.LAA07990@bush.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 5 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- Date: 2000-Aug-10 11:48 By: gvanrossum Comment: No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } ------------------------------------------------------- Date: 2000-Aug-10 11:51 By: gvanrossum Comment: Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code. ------------------------------------------------------- Date: 2000-Aug-10 21:57 By: tim_one Comment: It's curious that in the change mail SF generated, leading indentation was *not* lost. This must be a browser display thing. Anyway, by eyeball the syntax checker has two bugs: 1. Infinite loop when looking at an exponent. x while (isdigit(*s)) digits++; should be x while (isdigit(*s)) {digits++; s++;) 2. Like atof, stops at an invalid character. Before the x return s; it should have, e.g., x while (ispace(*s)) ++s; x if (*s) return NULL; although I'm not sure what the assumptions are about the input to this function. ------------------------------------------------------- Date: 2000-Aug-27 11:38 By: gvanrossum Comment: I'm mailing Tim a fixed version of floatsyntax(). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Sun Aug 27 20:20:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 12:20:25 -0700 Subject: [Python-bugs-list] [Bug #110616] source file stays open after parsing is done (PR#209) Message-ID: <200008271920.MAA01650@delerium.i.sourceforge.net> Bug #110616, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: source file stays open after parsing is done (PR#209) Details: Jitterbug-Id: 209 Submitted-By: Guido van Rossum Date: Tue, 22 Feb 2000 10:42:17 -0500 Version: None OS: None 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 ==================================================================== Audit trail: Wed Feb 23 21:30:38 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-27 12:20 By: gvanrossum Comment: Fixed as follows: Add three new APIs: PyRun_AnyFileEx(), PyRun_SimpleFileEx(), PyRun_FileEx(). These are the same as their non-Ex counterparts but have an extra argument, a flag telling them to close the file when done. Then this is used by Py_Main() and execfile() to close the file after it is parsed but before it is executed. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110616&group_id=5470 From noreply@sourceforge.net Sun Aug 27 21:47:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 13:47:38 -0700 Subject: [Python-bugs-list] [Bug #112123] bdist_wininst crashes with no long_description Message-ID: <200008272047.NAA12312@bush.i.sourceforge.net> Bug #112123, was updated on 2000-Aug-16 15:18 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: None Priority: 5 Summary: bdist_wininst crashes with no long_description Details: The bdist_wininst command crashes if no long_description is specified: File "setup.py", line 48, in ? sources = [ File "/www/python/lib/python1.5/site-packages/distutils/core.py", line 112, in setup dist.run_commands () File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 776, in run_commands self.run_command (cmd) File "/www/python/lib/python1.5/site-packages/distutils/dist.py", line 797, in run_command cmd_obj.run () File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 115, in run self.create_exe (arcname, fullname) File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 171, in create_exe cfgdata = open (self.create_inifile()).read() File "/www/python/lib/python1.5/site-packages/distutils/command/bdist_wininst.py", line 140, in create_inifile info = metadata.long_description + '\n' TypeError: bad operand type(s) for + Follow-Ups: Date: 2000-Aug-27 13:47 By: gward Comment: Thomas fixed this in the latest wininst code drop, but had some missing parens. I just added them and checked that in. Can please someone check that "long_description" behaves correctly with Windows installers? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112123&group_id=5470 From noreply@sourceforge.net Mon Aug 28 00:33:06 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 27 Aug 2000 16:33:06 -0700 Subject: [Python-bugs-list] [Bug #112877] re behaves differently in 1.6 and 2.0 than 1.52 Message-ID: <200008272333.QAA17657@bush.i.sourceforge.net> Bug #112877, was updated on 2000-Aug-27 16:33 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: re behaves differently in 1.6 and 2.0 than 1.52 Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0 http://dorb.com/python/testRe.py For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112877&group_id=5470 From noreply@sourceforge.net Mon Aug 28 08:34:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 00:34:38 -0700 Subject: [Python-bugs-list] [Bug #112693] re behaves differently in 1.6 and 2.0 than 1.52 Message-ID: <200008280734.AAA25935@delerium.i.sourceforge.net> Bug #112693, was updated on 2000-Aug-24 20:04 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: re behaves differently in 1.6 and 2.0 than 1.52 Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0 http://dorb.com/python/testRe.py Follow-Ups: Date: 2000-Aug-25 07:42 By: jhylton Comment: Just noting that we should resolve this bug before release. ------------------------------------------------------- Date: 2000-Aug-28 00:34 By: effbot Comment: The pattern causes excessive recursion (nested repeats on a long target string). SRE's stack check traps this, but the exception got lost on the way out. With the current CVS version, the example gives a "maximum recursion limit exceeded". That's an improvement, but not enough to close the bug... ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112693&group_id=5470 From noreply@sourceforge.net Mon Aug 28 08:37:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 00:37:10 -0700 Subject: [Python-bugs-list] [Bug #110671] Tk-based widgets misbehave with dead keys (PR#376) Message-ID: <200008280737.AAA25973@delerium.i.sourceforge.net> Bug #110671, was updated on 2000-Jul-31 14:12 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: None Bug Group: 3rd Party Priority: 5 Summary: Tk-based widgets misbehave with dead keys (PR#376) Details: Jitterbug-Id: 376 Submitted-By: fstajano@uk.research.att.com Date: Thu, 29 Jun 2000 12:49:44 -0400 (EDT) Version: 1.6a2 OS: Windows 98 and 2000 This is a problem of the underlying widget set and not of Idle itself, but Idle is where I encountered it (I normally use Emacs), and since Python 1.6 is the unicode version I suppose it's worth looking into anyway (what good is it to have international chars if you can't input them ;-)). If, on Windows, you use a keyboard layout with dead keys, such as "United States - International", then Idle does not respond properly to dead keys. In particular, double-quote comes out as single-quote; single-quote comes out as space; and accented characters come out as non-accented. The lack of support for the accented chars is a minor nuisance, but the problems with quotes are a major one -- Idle is almost unusable under these circumstances. Not as bad as Pythonwin, though, which just crashes. [As you will know, the US-I keyboard defines things like single-quote and double-quote as dead keys so that one can produce accents and umlauts respectively by following the dead key with the appropriate vowel. To produce a double-quote on its own, you have to press double-quote followed by space.] ==================================================================== Audit trail: Tue Jul 11 08:24:21 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-28 00:37 By: effbot Comment: This is supposed to be fixed in Tk 8.3 and later; from the 8.3.0 changes document: 2000-02-08 (bug fix) fixed incorrect handling of CapsLock on Win9* and the use of dead keys on international keyboards (spjuth) (haven't verified it yet, since 1.6's Tkinter causes my Win95 box to crash, no matter what Tk version I'm using) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110671&group_id=5470 From noreply@sourceforge.net Mon Aug 28 08:53:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 00:53:15 -0700 Subject: [Python-bugs-list] [Bug #112877] re behaves differently in 1.6 and 2.0 than 1.52 Message-ID: <200008280753.AAA26512@delerium.i.sourceforge.net> Bug #112877, was updated on 2000-Aug-27 16:33 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Duplicate Bug Group: None Priority: 5 Summary: re behaves differently in 1.6 and 2.0 than 1.52 Details: The output is diffrent when run with 1.52 when compared with 1.6 or 2.0 http://dorb.com/python/testRe.py Follow-Ups: Date: 2000-Aug-28 00:53 By: effbot Comment: same as #112693 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112877&group_id=5470 From noreply@sourceforge.net Mon Aug 28 08:49:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 00:49:16 -0700 Subject: [Python-bugs-list] [Bug #111705] problems with re.py and regex.py Message-ID: <200008280749.AAA26359@delerium.i.sourceforge.net> Bug #111705, was updated on 2000-Aug-11 12:19 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: Works For Me Bug Group: Irreproducible Priority: 5 Summary: problems with re.py and regex.py Details: Hi, here is something I have been working on for quite some time. I always thought it was my regex syntax, but I was incorrect. I tried it in perl, and php, and both worked fine. re.py has a problem with ([_a-zA-Z0-9-]\.*) where it hangs during compilation. regex.py has a problem with ([a-zA-Z]){2,3} (or any other similar statement) where it does not limit the number of characters properly. Here is the code ... import string import sys import regex def testemailaddr(emailaddr): pattern = regex.compile('^([_a-zA-Z0-9-]\.*){3,255}@([_a-zA-Z0-9-]\.*){3,255}\.([a-zA-Z]){2,3}$') if pattern.match(emailaddr) != None: valid = [1, emailaddr] else: valid = [0, emailaddr] return valid validemail = testemailaddr(sys.argv[1]) if validemail[0] == 1: print validemail[1], "is valid." else: print validemail[1], "is not valid." Follow-Ups: Date: 2000-Aug-28 00:49 By: effbot Comment: 'regex' doesn't support {} repeat syntax (see the docs for details). and the given pattern doesn't hang during compilation, whether I'm using 1.5.2's re module (the PCRE engine), 1.6's re module (SRE), or 1.6's pre module (PCRE). to reopen this bug, please submit an example that includes a sample target string (emailaddr). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111705&group_id=5470 From noreply@sourceforge.net Mon Aug 28 15:12:48 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 07:12:48 -0700 Subject: [Python-bugs-list] [Bug #110865] Reproducible crash of Mac IDE (PR#172) Message-ID: <200008281412.HAA06907@delerium.i.sourceforge.net> Bug #110865, was updated on 2000-Aug-01 14:40 Here is a current snapshot of the bug. Project: Python Category: None Status: Closed Resolution: None Bug Group: 3rd Party Priority: 5 Summary: Reproducible crash of Mac IDE (PR#172) Details: Jitterbug-Id: 172 Submitted-By: Bruce.Sherwood@cmu.edu Date: Fri, 7 Jan 2000 11:21:23 -0500 (EST) Version: 1.5.2c1 OS: Mac 8.1 I'm writing tiny programs invoking Tkinter, to learn how to use it. If I open my script from the Mac IDE and click "Run all" in the script title bar, the script runs okay, but when I try to quit running, the entire IDE locks up. I have to do an unpleasant Mac "Force quit" to get out. This is completely reproducible with tiny programs containing "from Tkinter import *". I've had to resort to the awkward strategem of saving the script, then dragging the script file onto the Python interpreter. In that case I can quit normally. It means that I'm only using the IDE as a (structured) text editor. I don't have the quit problem in Mac IDE with scripts that don't invoke Tkinter. ==================================================================== Audit trail: Wed Jan 12 18:28:11 2000 guido sent reply 1 Wed Jan 12 18:28:24 2000 guido changed notes Wed Jan 12 18:28:24 2000 guido moved from incoming to 3rdpartybug Follow-Ups: Date: 2000-Aug-01 14:41 By: none Comment: From: Guido van Rossum Subject: Re: Reproducible crash of Mac IDE (PR#172) Date: Wed Jan 12 18:28:11 2000 > Full_Name: Bruce Sherwood > Version: 1.5.2c1 > OS: Mac 8.1 > Submission from: hejmo.rem.cmu.edu (128.2.83.199) > > > I'm writing tiny programs invoking Tkinter, to learn how to use it. If I open my > script from the Mac IDE and click "Run all" in the script title bar, the script > runs okay, but when I try to quit running, the entire IDE locks up. I have to do > an unpleasant Mac "Force quit" to get out. This is completely reproducible with > tiny programs containing "from Tkinter import *". > > I've had to resort to the awkward strategem of saving the script, then dragging > the script file onto the Python interpreter. In that case I can quit normally. > It means that I'm only using the IDE as a (structured) text editor. > > I don't have the quit problem in Mac IDE with scripts that don't invoke > Tkinter. Bruce, Are you using the default Python IDE or the separate (much nicer) IDE by my brother Just? In either case, you are probably better of trying to learn Tkinter on a Unix or Windows platform; it is unfortunately notoriously unstable on the Mac, and there's not a lot we can do about this. --Guido van Rossum ------------------------------------------------------- Date: 2000-Aug-01 14:41 By: none Comment: From: Just van Rossum Subject: Re: Reproducible crash of Mac IDE (PR#172) Date: Thu, 13 Jan 2000 01:30:38 +0100 At 6:28 PM -0500 12-01-2000, Guido van Rossum wrote: >> Full_Name: Bruce Sherwood >> Version: 1.5.2c1 >> OS: Mac 8.1 >> Submission from: hejmo.rem.cmu.edu (128.2.83.199) >> >> >> I'm writing tiny programs invoking Tkinter, to learn how to use it. If I >>open >my >> script from the Mac IDE and click "Run all" in the script title bar, the >script >> runs okay, but when I try to quit running, the entire IDE locks up. I >>have to >do >> an unpleasant Mac "Force quit" to get out. This is completely reproducible >with >> tiny programs containing "from Tkinter import *". >> >> I've had to resort to the awkward strategem of saving the script, then >dragging >> the script file onto the Python interpreter. In that case I can quit >normally. >> It means that I'm only using the IDE as a (structured) text editor. >> >> I don't have the quit problem in Mac IDE with scripts that don't invoke >> Tkinter. I'm sorry to inform you that the Mac Python IDE is not compatible with Tkinter. At all. Conflicting event loops and all. Sorry! Just ------------------------------------------------------- Date: 2000-Aug-01 14:41 By: none Comment: From: Bruce Sherwood Subject: Re: Reproducible crash of Mac IDE (PR#172) Date: Wed, 12 Jan 2000 23:47:18 -0500 --On Thu, Jan 13, 2000 01:30 +0100 Just van Rossum wrote: > I'm sorry to inform you that the Mac Python IDE is not compatible with > Tkinter. At all. Conflicting event loops and all. Thanks for the confirmation. At least now I won't keep suspecting it's me the novice at fault! Bruce Sherwood ------------------------------------------------------- Date: 2000-Aug-01 14:41 By: none Comment: From: Bruce Sherwood Subject: Re: Reproducible crash of Mac IDE (PR#172) Date: Thu, 13 Jan 2000 01:00:41 -0500 --On Wed, Jan 12, 2000 18:28 -0500 Guido van Rossum wrote: > Bruce, > > Are you using the default Python IDE or the separate (much nicer) IDE > by my brother Just? > > In either case, you are probably better of trying to learn Tkinter on > a Unix or Windows platform; it is unfortunately notoriously unstable > on the Mac, and there's not a lot we can do about this. > > --Guido van Rossum I'm not sure of terminology. I was trying to use what is called (on disk) "Python IDE" and whose About Box when running says "The Python Integrated Development Environment" version 1.0 by Just. I don't think I've seen anything else called IDE on the Mac. Just's note to me seems to confirm that I was using his environment, which he explains won't work with tkinter. So I'll stop trying that! I didn't expect to hear directly from you, Guido, in response to my bug report. Thanks for writing. Some colleagues and I were planning on talking with you in depth about your strong interest in computer programming for everybody, which is of deep concern to us, too. But we only just started learning Python and were going to hold off from approaching you until we knew enough not to seem total idiots. But since you took the time to write to me, I'm encouraged to play the half-idiot and indicate our interest now. We would welcome deeper discussion if you perceive a community of interest. We're 200% in agreement with your stirring essay. Ordinary mortals ought to be able to write computer programs! We ourselves have worked hard on this problem for 30 years, with significant but little-known success in the particular niche of college faculty and students writing interactive graphics-oriented educational software. We're very impressed by the quality of what you have done in creating Python, and we believe it can be a solid foundation for programming for everybody. The exceptionally clean syntax, uncluttered by semicolons and ends and brackets, is important for nonexperts. We think Python has the potential to be a better foundation than our own cT programming language, and we would like to explore ways in which to contribute to the goal and vision you have articulated. Not only do we have long and deep experience in making it possible for nonexperts to write interactive graphics programs, but we are also involved in teaching an introductory college physics course in which students do graphics-oriented programming to carry out computer modeling of physical systems. Many of these students have never written a program before (for the reasons you discuss), yet toward the end of just two 50-minute periods of instruction the students are writing a program to calculate and display the motion of a spacecraft going from the Earth to the Moon. They do many such computer modeling projects during the semester. And they do this on Windows, Mac, and Linux, with the language, the graphics, and the programming environment all identical on all machines, with trivially easy installation and use, unplagued by problems of search paths, etc. Concretely, here is what we can offer in support of your goal: 1) If a graphics-oriented, multiplatform, Python-based environment suitable for novices can be developed, we have a physics course that we teach in which its deployment could be tested. So we offer a potential testbed for your DARPA project. I note in your essay your interest in what the University of Chicago can provide as a testbed for teaching the language. We can broaden the range of issues to include the case of a physics course where little time can be spent teaching programming, since the focus is on the physics, not the computer science, and where scientific graphics is central to the enterprise. 2) We can contribute to the design of such an environment, based on our long experience of developing and teaching and using a graphics-oriented, multiplatform programming language accessible to nonexperts. One of my colleagues can offer significant system expertise with the Mac (in addition to expertise with Windows and Linux). Mac systems expertise seems to be in short supply in the nation, yet the Mac is still very important in many educational settings. 3) Another of my colleagues has a particularly strong interest in designing and implementing powerful 3D scientific graphics in a way that would be usable by novices, based on Python. The possibilities this opens up for our physics course provide one of the main reasons for our interest in going beyond what is practical within the structures of cT, mainly because cT is not really object-oriented. Note that this is a different graphics issue than the one explored by Randy Pausch: it isn't a question of using Python to manipulate 3D models but doing such things as planetary orbits in 3D, from first principles. An area that cries out for 3D visualization is magnetism, where magnetic fields are inherently 3D objects. Another colleague has produced 3D movies of electric and magnetic fields in space, but these are not interactive and should be, when that is possible in the future. As I said, we weren't going to approach you until we knew more about Python. One of the reasons I've signaled our interest prematurely is that we find we need some guidance in the graphics area. We've been playing with tkinter since it seemed to have the largest community, but apparently there are LOTS of graphics environments in use with Python. We need some advice on plausible directions to go for graphics, and what makes sense as a foundation for extending to 3D scientific computer animation usable by novices. We believe that good novice-friendly graphics are absolutely critical to computer programming for everybody. There certainly are some "everybodies" who mostly want and need to sort lists or calculate mathematical functions or search files. But in our experience what grabs most everybodies is the instant gratification of starting with graphics. In the first 50 minutes of instruction our students have blue balls bouncing around inside a red box. This is powerful stuff and highly motivating. To us, graphics is utterly central to the goal of computer programming for everybody. And it is critical to our physics course. Bruce Sherwood Center for Innovation in Learning and Department of Physics Carnegie Mellon University http://cil.andrew.cmu.edu/bruce.sherwood.html P.S. Sorry about reporting the tkinter bug with arcs to you rather than to the Tk people. I didn't quite see how to report it to them and figured that if I sent it to Python it would get to the right person eventually. I am now using oval rather than arc to avoid the bug, though in an algorithmic situation one might compute the extent of an arc, and if it comes out to be 360, too bad -- you'll get a line instead of an oval. ------------------------------------------------------- Date: 2000-Aug-01 14:41 By: none Comment: Not much we can do about this, probably. ------------------------------------------------------- Date: 2000-Aug-28 07:12 By: jhylton Comment: Just says that this is a known incompatibility, which he is working on. It is not a Python bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110865&group_id=5470 From noreply@sourceforge.net Mon Aug 28 15:41:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 07:41:01 -0700 Subject: [Python-bugs-list] [Bug #110623] build on NeXTStep (PR#240) Message-ID: <200008281441.HAA15085@bush.i.sourceforge.net> Bug #110623, was updated on 2000-Jul-31 14:07 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Wont Fix Bug Group: Platform-specific Priority: 5 Summary: build on NeXTStep (PR#240) Details: Jitterbug-Id: 240 Submitted-By: kragen@pobox.com (Kragen Sitaker) Date: Fri, 17 Mar 2000 16:09:19 -0500 (EST) Version: None OS: None I'm building Python on NeXTStep; I've encountered three minor problems. - importdl.c by default on NeXTStep allows linking with Objective-C modules, which is cool. Unfortunately, properly supporting this requires adding -ObjC to the cc command line in the Makefile. - posixmodule.c doesn't #include anything that declares fsync() and doesn't declare it itself, but tries to reference it. Adding a declaration of fsync() fixes the problem. - test_strftime and test_time fail. test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' I suspect this may be a platform bug. Here's some of the output, which is 696 lines in full: strftime test for Fri Mar 17 12:53:20 2000 Strftime test, platform: next3_3, Python version: 1.5.2 Conflict for %j (julian day (001-366)): Expected 077, but got 076 Conflict for nonstandard '%c' format (near-asctime() format): Expected Fri Mar 17 12:53:20 2000, but got Fri Mar 17 12:53:20 2000 Conflict for nonstandard '%x' format (%m/%d/%y %H:%M:%S): Expected 03/17/00, but got Fri Mar 17 2000 Does not appear to support '%Z' format (time zone name) Conflict for nonstandard '%D' format (mm/dd/yy): Expected 03/17/00, but got ? Conflict for nonstandard '%e' format (day of month as number, blank padded ( 0-31)): Expected 17, but got ? Conflict for nonstandard '%h' format (abbreviated month name): Expected Mar, but got ? Conflict for nonstandard '%k' format (hour, blank padded ( 0-23)): Expected 12, but got ? Conflict for nonstandard '%n' format (newline character): Expected , but got ? Conflict for nonstandard '%r' format (%I:%M:%S %p): Expected 12:53:20 PM, but got ? Conflict for nonstandard '%R' format (%H:%M): Expected 12:53, but got ? Conflict for nonstandard '%s' format (seconds since the Epoch in UCT): Expected 953326400, but got ? Conflict for nonstandard '%t' format (tab character): Expected , but got ? Conflict for nonstandard '%T' format (%H:%M:%S): Expected 12:53:20, but got ? Conflict for nonstandard '%3y' format (year without century rendered using fieldwidth): Expected 000, but got ?y Conflict for %j (julian day (001-366)): Expected 327, but got 326 Conflict for %W (week number of the year (Mon 1st)): Expected 46, but got 47 Conflict for %j (julian day (001-366)): Expected 328, but got 327 Conflict for %j (julian day (001-366)): Expected 329, but got 328 Conflict for %j (julian day (001-366)): Expected 330, but got 329 test test_time failed -- Writing: 'time.mktime(time.localtime(t)) <> t', expected: '' (and that was all of the output from test_time. Presumably this is related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports 'Command not found'. I'm not trying to build a very sophisticated environment --- just the defaults. -- Kragen Sitaker The Internet stock bubble didn't burst on 1999-11-08. Hurrah! The power didn't go out on 2000-01-01 either. :) ==================================================================== Audit trail: Mon Apr 03 18:40:11 2000 guido changed notes Mon Apr 03 18:40:11 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:07 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Fri, 24 Mar 2000 10:05:14 -0500 > I'm building Python on NeXTStep; I've encountered three minor problems. > > - importdl.c by default on NeXTStep allows linking with Objective-C > modules, which is cool. Unfortunately, properly supporting this > requires adding -ObjC to the cc command line in the Makefile. > - posixmodule.c doesn't #include anything that declares fsync() and > doesn't declare it itself, but tries to reference it. Adding a > declaration of fsync() fixes the problem. > - test_strftime and test_time fail. > test test_strftime failed -- Writing: 'Conflict for %j (julian day (001-366)):', expected: '' > I suspect this may be a platform bug. Here's some of the output, > which is 696 lines in full: [...] > (and that was all of the output from test_time. Presumably this is > related to the strftime bugs --- perhaps the mythical Y2K leap-year bug?) > > I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports > 'Command not found'. > > I'm not trying to build a very sophisticated environment --- just the > defaults. Kragen, Can you send us some patches? We don't have a NextStep system around to test any of this, and your description of the problem doesn't help me to create fixes that will certainly work for you. There's probably not much you can do about the strftime problem -- just don't use time.strftime()! :-) Please read python.org/patches for info on how to submit patches. Thanks for contributing! --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:07 By: none Comment: From: kragen@pobox.com (Kragen Sitaker) Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Tue, 28 Mar 2000 12:46:18 -0500 (EST) Guido writes: > [Kragen wrote:] > > I'm afraid I'm not sure what version of NeXTStep I'm on. 'arch' > > reports 'hppa'; 'cc --version' reports '2.5.8'; 'uname -a' reports > > 'Command not found'. It's NeXTStep 3.3. > Can you send us some patches? We don't have a NextStep system around > to test any of this, and your description of the problem doesn't help > me to create fixes that will certainly work for you. I can send a patch for importdl.c; the right thing to do for this would be to modify the Makefile to change the flags passed to the compiler to include -ObjC, but I don't know how to do that. My solution was to change a #define in the source to turn off the ability to import Objective-C modules, which is obviously far from optimal --- thus my failure to include a patch for this in the first email. In posixmodule.c, which needs fsync() declared, I'm not sure where to declare it. I can certainly supply a patch that works for NeXTStep 3.3, but I don't understand the rat's-nest of #ifdefs there well enough to be sure it won't break compilation on some other platform, or even another version of NeXTStep --- thus my failure to include a patch for this in the first email. So I can send patches for both of these, but I am not sure if I should. > Please read python.org/patches for info on how to submit patches. Thanks. -- Kragen Sitaker The Internet stock bubble didn't burst on 1999-11-08. Hurrah! The power didn't go out on 2000-01-01 either. :) ------------------------------------------------------- Date: 2000-Jul-31 14:07 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] build on NeXTStep (PR#240) Date: Tue, 28 Mar 2000 14:41:28 -0500 > It's NeXTStep 3.3. > > > Can you send us some patches? We don't have a NextStep system around > > to test any of this, and your description of the problem doesn't help > > me to create fixes that will certainly work for you. > > I can send a patch for importdl.c; the right thing to do for this would > be to modify the Makefile to change the flags passed to the compiler to > include -ObjC, but I don't know how to do that. My solution was to > change a #define in the source to turn off the ability to import > Objective-C modules, which is obviously far from optimal --- thus my > failure to include a patch for this in the first email. > > In posixmodule.c, which needs fsync() declared, I'm not sure where to > declare it. I can certainly supply a patch that works for NeXTStep > 3.3, but I don't understand the rat's-nest of #ifdefs there well enough > to be sure it won't break compilation on some other platform, or even > another version of NeXTStep --- thus my failure to include a patch for > this in the first email. > > So I can send patches for both of these, but I am not sure if I should. Maybe we should just drop it? I don't think NextStep 3.3 has much future or even much current use, does it? it's only supported for historic reasons. If you get it to work, fine -- but I don't think the general public would benefit much from adding NS 3.3 support... Or am I wrong? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-28 07:41 By: jhylton Comment: Kragen says thius bug report is probably only useful as proof that it is possible to get Python to build on Nextstep 3.2 on Hp-HPs. A closed bug report should satisfy that need as well as an open one. Not opposed to patches to allow builds under nextstep, but no one has the expertise to provide them. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110623&group_id=5470 From noreply@sourceforge.net Mon Aug 28 15:49:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 07:49:59 -0700 Subject: [Python-bugs-list] [Bug #111818] .../test/test_fork1 hangs Message-ID: <200008281449.HAA15435@bush.i.sourceforge.net> Bug #111818, was updated on 2000-Aug-13 17:25 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: .../test/test_fork1 hangs Details: .../test/test_fork1 never terminates on Python1.6b1 which runs on RedHat Linux: uname -a gives Linux pclab55.research.bell-labs.com 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown gcc 2.91.66 OPT set to -O -g (also with -O2 -g) configuration is --with-thread --prefix=/u/gpkdata/Linux An identically compuled system (except gcc 2.95.1 ) on Solaris 2.6 operates properly. Follow-Ups: Date: 2000-Aug-28 07:49 By: jhylton Comment: fixed by patch 101226 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111818&group_id=5470 From noreply@sourceforge.net Mon Aug 28 16:40:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 08:40:50 -0700 Subject: [Python-bugs-list] [Bug #112943] PythonWin crashes on wierd class definition Message-ID: <200008281540.IAA10264@delerium.i.sourceforge.net> Bug #112943, was updated on 2000-Aug-28 08:40 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Summary: PythonWin crashes on wierd class definition Details: Hello! PythonWin crashes when trying to run the following code Hello! PythonWin 1.5.2 (build 132) crashes (on WinNT 4.0) on the following code. class X: def __init__(self,x): self.val = x def __add__(x,y): return X(x.val + y.val) def __radd__(x,y): return y + x if __name__ == '__main__': x = X(4) y = 3 + x For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112943&group_id=5470 From noreply@sourceforge.net Mon Aug 28 16:49:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 08:49:37 -0700 Subject: [Python-bugs-list] [Bug #112943] PythonWin crashes on weird class definition Message-ID: <200008281549.IAA17700@bush.i.sourceforge.net> Bug #112943, was updated on 2000-Aug-28 08:40 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 9 Summary: PythonWin crashes on weird class definition Details: Hello! PythonWin crashes when trying to run the following code Hello! PythonWin 1.5.2 (build 132) crashes (on WinNT 4.0) on the following code. class X: def __init__(self,x): self.val = x def __add__(x,y): return X(x.val + y.val) def __radd__(x,y): return y + x if __name__ == '__main__': x = X(4) y = 3 + x Follow-Ups: Date: 2000-Aug-28 08:49 By: gvanrossum Comment: Hello! The example causes endless recursion on __radd__. (You should have said "return x+y" there.) Hello! It is still a bug in 2.0b1! Should be fixed. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112943&group_id=5470 From noreply@sourceforge.net Mon Aug 28 16:58:08 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 08:58:08 -0700 Subject: [Python-bugs-list] [Bug #112943] infinite recursion bug Message-ID: <200008281558.IAA18054@bush.i.sourceforge.net> Bug #112943, was updated on 2000-Aug-28 08:40 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 9 Summary: infinite recursion bug Details: Hello! PythonWin crashes when trying to run the following code Hello! PythonWin 1.5.2 (build 132) crashes (on WinNT 4.0) on the following code. class X: def __init__(self,x): self.val = x def __add__(x,y): return X(x.val + y.val) def __radd__(x,y): return y + x if __name__ == '__main__': x = X(4) y = 3 + x Follow-Ups: Date: 2000-Aug-28 08:49 By: gvanrossum Comment: Hello! The example causes endless recursion on __radd__. (You should have said "return x+y" there.) Hello! It is still a bug in 2.0b1! Should be fixed. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112943&group_id=5470 From noreply@sourceforge.net Mon Aug 28 17:03:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 09:03:04 -0700 Subject: [Python-bugs-list] [Bug #112944] Second import of module succeeds even if first import failed Message-ID: <200008281603.JAA18236@bush.i.sourceforge.net> Bug #112944, was updated on 2000-Aug-28 09:03 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Second import of module succeeds even if first import failed Details: The second import of a library that failed the first time does not re-initialize the module, and returns a reference to the uninitialized module: >>> import cPickle Traceback (most recent call last): File "", line 1, in ? ImportError: No module named copy_reg >>> ^P File "", line 1 ^ SyntaxError: invalid syntax >>> import cPickle >>> Subsequent use of the uninitialized module crashes the interpreter: >>> cPickle.Pickler() Segmentation fault (core dumped) (and it happens the same way in scripts.) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112944&group_id=5470 From noreply@sourceforge.net Mon Aug 28 17:05:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 09:05:58 -0700 Subject: [Python-bugs-list] [Bug #110615] another unbounded recursion bug Message-ID: <200008281605.JAA18322@bush.i.sourceforge.net> Bug #110615, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 9 Summary: another unbounded recursion bug Details: Jitterbug-Id: 207 Submitted-By: vincent@ldsol.com Date: Wed, 16 Feb 2000 10:31:02 -0500 (EST) Version: 1.5.2 OS: Linux 2.2.x 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, ==================================================================== Audit trail: Wed Feb 23 21:28:40 2000 guido changed notes Wed Feb 23 21:28:40 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:06 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 10:57:29 -0500 > 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/) ------------------------------------------------------- Date: 2000-Jul-31 14:06 By: none Comment: From: Vincent Renardias Subject: Re: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 16:39:51 +0000 (GMT) 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] ------------------------------------------------------- Date: 2000-Jul-31 14:06 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 20:36:03 -0500 [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. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110615&group_id=5470 From noreply@sourceforge.net Mon Aug 28 17:06:16 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 09:06:16 -0700 Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate Message-ID: <200008281606.JAA18326@bush.i.sourceforge.net> Bug #111403, was updated on 2000-Aug-08 11:26 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: 1.6b1 dumps core dereferencing a NULL tstate Details: This is from an embeded python. I've not yet been able to reproduce this with a small example. But perhaps this stacktrace will be of some help. The problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back. This pointer is dereferenced in PyFrame_New() later on which causes the core dump. The documentation seems to say that PyThreadState_GET() should never return NULL. So, there must be a bug in there somewhere. Here is the stack trace: #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 120 PyFrameObject *back = tstate->frame; (gdb) bt #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 #1 0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x925d2e8) at ceval.c:397 #2 0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0) at ceval.c:2521 #3 0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, kw=0x0) at ceval.c:2359 #4 0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0) at abstract.c:1370 #5 0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80) at DrawingArea.C:971 #6 0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027 #7 0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169 #8 0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1) at ./tclUnixNotfy.c:405 #9 0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444 #10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747 #11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0) at ./_tkinter.c:1794 #12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2396 #13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2361 #14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, defcount=1, owner=0x0) at ceval.c:1680 #15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, defcount=0, owner=0x92c6238) at ceval.c:1579 #16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038) at ceval.c:290 #19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885 #20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870 #21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847 #22 0x867ce4e in PyRun_SimpleString ( command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589 #23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248 #24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30 Mike Romberg (romberg@fsl.noaa.gov) Follow-Ups: Date: 2000-Aug-10 10:23 By: none Comment: Followup: This only happens when python is built --with-threads. There appears to be no problem when threads are not enabled. It should be noted that our embeded application uses no threads of any kind (python or pthreads from C++). But it may be the case that our code (C++) is not doing the right thing. It should be noted that our application works fine with python-1.5.2 compiled --with-threads. ------------------------------------------------------- Date: 2000-Aug-25 07:37 By: jhylton Comment: Mike -- Can you provide any more information about this bug? ------------------------------------------------------- Date: 2000-Aug-25 09:59 By: romberg Comment: My guess (and this is just a guess) is that this may have something to do with the interaction of python threads and Tkinter. Since most of our embeded (and non threaded) python application works fine except for one specific area, maybe that is thre problem with python 1.6. Let me attempt to explain what is going on since it may take some work to produce a small test case to reproduce the problem. Our application uses Tkinter for most of the UI. We do open a second connection to the X server using Xlib. This connection is used to render complex images into windows. Tkinter's canvas is just not fast enough. I am getting X events from these Xlib created windows via the Tcl/Tk FileEventHandler (as seen on the stack trace). I am using the Tcl/Tk C API to register for these events. The case which seems to cause the crash in python comes when I get a ButtonDown event on my second (non Tkinter) Display. This event is delivered from Tcl/Tk to some of our C++ code. Now for the interesting bit which I suspect might cause the problem. Our C++ code then releases the grab and calls into the python interpreter for it to post a popup menu (using Tkinter). This is seen on the stack as the most recent PyObject_CallObject(). This code attempts to post the Tkinter popuip menu but dies trying. This works fine under python-1.5.2 when it is built --with-thread and without. It works fine with python-1.6b2 as long as python is built without threads. But when it is built with threads I get this crash. Is it possible that the Tkinter layer is doing something different threadwise when python is built --with-threads? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470 From noreply@sourceforge.net Mon Aug 28 17:07:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 09:07:28 -0700 Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate Message-ID: <200008281607.JAA18440@bush.i.sourceforge.net> Bug #111403, was updated on 2000-Aug-08 11:26 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 7 Summary: 1.6b1 dumps core dereferencing a NULL tstate Details: This is from an embeded python. I've not yet been able to reproduce this with a small example. But perhaps this stacktrace will be of some help. The problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back. This pointer is dereferenced in PyFrame_New() later on which causes the core dump. The documentation seems to say that PyThreadState_GET() should never return NULL. So, there must be a bug in there somewhere. Here is the stack trace: #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 120 PyFrameObject *back = tstate->frame; (gdb) bt #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 #1 0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x925d2e8) at ceval.c:397 #2 0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0) at ceval.c:2521 #3 0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, kw=0x0) at ceval.c:2359 #4 0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0) at abstract.c:1370 #5 0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80) at DrawingArea.C:971 #6 0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027 #7 0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169 #8 0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1) at ./tclUnixNotfy.c:405 #9 0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444 #10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747 #11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0) at ./_tkinter.c:1794 #12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2396 #13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2361 #14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, defcount=1, owner=0x0) at ceval.c:1680 #15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, defcount=0, owner=0x92c6238) at ceval.c:1579 #16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038) at ceval.c:290 #19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885 #20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870 #21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847 #22 0x867ce4e in PyRun_SimpleString ( command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589 #23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248 #24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30 Mike Romberg (romberg@fsl.noaa.gov) Follow-Ups: Date: 2000-Aug-10 10:23 By: none Comment: Followup: This only happens when python is built --with-threads. There appears to be no problem when threads are not enabled. It should be noted that our embeded application uses no threads of any kind (python or pthreads from C++). But it may be the case that our code (C++) is not doing the right thing. It should be noted that our application works fine with python-1.5.2 compiled --with-threads. ------------------------------------------------------- Date: 2000-Aug-25 07:37 By: jhylton Comment: Mike -- Can you provide any more information about this bug? ------------------------------------------------------- Date: 2000-Aug-25 09:59 By: romberg Comment: My guess (and this is just a guess) is that this may have something to do with the interaction of python threads and Tkinter. Since most of our embeded (and non threaded) python application works fine except for one specific area, maybe that is thre problem with python 1.6. Let me attempt to explain what is going on since it may take some work to produce a small test case to reproduce the problem. Our application uses Tkinter for most of the UI. We do open a second connection to the X server using Xlib. This connection is used to render complex images into windows. Tkinter's canvas is just not fast enough. I am getting X events from these Xlib created windows via the Tcl/Tk FileEventHandler (as seen on the stack trace). I am using the Tcl/Tk C API to register for these events. The case which seems to cause the crash in python comes when I get a ButtonDown event on my second (non Tkinter) Display. This event is delivered from Tcl/Tk to some of our C++ code. Now for the interesting bit which I suspect might cause the problem. Our C++ code then releases the grab and calls into the python interpreter for it to post a popup menu (using Tkinter). This is seen on the stack as the most recent PyObject_CallObject(). This code attempts to post the Tkinter popuip menu but dies trying. This works fine under python-1.5.2 when it is built --with-thread and without. It works fine with python-1.6b2 as long as python is built without threads. But when it is built with threads I get this crash. Is it possible that the Tkinter layer is doing something different threadwise when python is built --with-threads? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470 From noreply@sourceforge.net Mon Aug 28 17:08:19 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 09:08:19 -0700 Subject: [Python-bugs-list] [Bug #110864] PRIVATE: Unhandled exception in python.exe (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) Message-ID: <200008281608.JAA18467@bush.i.sourceforge.net> Bug #110864, was updated on 2000-Aug-01 14:39 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: Irreproducible Priority: 1 Summary: PRIVATE: Unhandled exception in python.exe (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) Details: Jitterbug-Id: 364 Submitted-By: tong@aristotech.com Date: Tue, 20 Jun 2000 18:38:41 -0400 (EDT) Version: 1.5 OS: win NT We just moved to msvc6.0 and since then, some of our developers (including myself)will crash on following every time we run from msvc debugger: c:\vsvc98\crt\src\sbheap.c // test if previous entry was free with an index change or allocated if (!((sizePrev & 1) == 0 && indPrev == indEntry)) { // connect pEntry entry to indEntry // add entry to the start of the bucket list pHead = (PENTRY)((char *)&pGroup->listHead[indEntry] - sizeof(int)); pEntry->pEntryNext = pHead->pEntryNext; pEntry->pEntryPrev = pHead; pHead->pEntryNext = pEntry; pEntry->pEntryNext->pEntryPrev = pEntry; I'm using NT4.0 service pack 6 but developers who use service pack4 and pack5 also encouter this problem. We use python/tk. ==================================================================== Audit trail: Tue Jul 11 08:24:19 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:40 By: none Comment: From: "Mark Hammond" Subject: RE: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) Date: Wed, 21 Jun 2000 09:57:40 +1000 It appears you have simply quoted the code from the MSVC runtime library. Can you give us some details about the script that is running? Does it use any extension modules? You should also be able to provide the complete stack trace when the program crashes, as shown in the MSVC debugger "Call Stack" window. If you can provide this, we will be able to look into it further. However, Python is used successfully in many many projects. The most likely candidate is your own C code, if any exists in the project. If not, the next most likely candidate is mixing the CRT library versions - you mention MSVCRTD.DLL. You must ensure that _all_ code loaded, including Python itself, is using this debug DLL. This generally means you need to be running with the "_d" versions of the Python binaries, and with all your code compiled with "/MDd". Carefully check the MSVC "Output" window - there should be exactly one reference to "msvcrt.dll" _or_ exactly one reference to "msvcrtd.dll" - if references to both exist, or the same DLL name from different directories has been loaded twice, that is your problem. Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > tong@aristotech.com > Sent: Wednesday, 21 June 2000 8:39 AM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] PRIVATE: Unhandled exception in python.exe > (MSVCRTD.DLL): 0Xc0000005: Access Violation (PR#364) > > > Full_Name: Siu-Tong Hui > Version: 1.5 > OS: win NT > Submission from: node-d8e9472.powerinter.net (216.233.71.2) > > > We just moved to msvc6.0 and since then, some of our developers > (including > myself)will crash on following every time we run from msvc debugger: > > c:\vsvc98\crt\src\sbheap.c > // test if previous entry was free with an index change or allocated > if (!((sizePrev & 1) == 0 && indPrev == indEntry)) > { > // connect pEntry entry to indEntry > // add entry to the start of the bucket list > pHead = (PENTRY)((char *)&pGroup->listHead[indEntry] - > sizeof(int)); > pEntry->pEntryNext = pHead->pEntryNext; > pEntry->pEntryPrev = pHead; > pHead->pEntryNext = pEntry; > pEntry->pEntryNext->pEntryPrev = pEntry; > > I'm using NT4.0 service pack 6 but developers who use service > pack4 and pack5 > also encouter this problem. > > We use python/tk. > > > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list > ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110864&group_id=5470 From noreply@sourceforge.net Mon Aug 28 17:16:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 09:16:02 -0700 Subject: [Python-bugs-list] [Bug #110915] compiler core-dumps on illegal continue Message-ID: <200008281616.JAA18697@bush.i.sourceforge.net> Bug #110915, was updated on 2000-Aug-02 05:13 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: compiler core-dumps on illegal continue Details: On my RedHat 6.2 system, the latest CVS version of python still dumps core on the following script: ------------------------------------------------- def gentheta(): while 1: try: continue finally: pass def genkappa(): if whatsmounted!='crystal': mountcrystal() while 1: if not inhibitmake: projtls.moveoutofway('kappa',dirok=1) os.mkdir('kappa') os.chdir('kappa') try: announce("Testing Kappa zero-point") # Use the detalign.vic produced by the dx calibration dal=os.path.join('..','dx','detalign.vic') if os.path.exists(dal): print "NOTE: Using detalign.vic from dx calibration" filecopy(dal,'detalign.vic') if not inhibitmake: status=os.system('calkappa make') else: status=os.system('calkappa') if status!=0: beeper.on() answer=command.question(root,'Calkappa Warnings',text='Calkappa issued some warnings and/or errors.\nPlease check what they are, and tell me what to do', strings=("Ignore them","Retry calkappa","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break if os.path.exists('instruct.txt'): beeper.on() answer=command.fixedfontquestion( root,'Kappa missetting needs correction', text=open('instruct.txt').read(), strings=("I have now done this","I'm ignoring this for now","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break else: # No instructions means no correction required break finally: os.chdir('..') ------------------------------------------- Any simplification in the second function makes the compiler report the "SyntaxError: continue not properly in loop" in line 4. Stack trace: ------------------------------------------- no203[140]~%3% gdb =python GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run x.py Starting program: /usr/local/nonius/bin/python x.py Program received signal SIGSEGV, Segmentation fault. PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 153 if (PyClass_Check(type)) { (gdb) where #0 PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 #1 0x8063901 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:672 #2 0x80638d6 in PyErr_Print () at pythonrun.c:663 #3 0x806368b in PyRun_SimpleFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:574 #4 0x806335d in PyRun_AnyFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:458 #5 0x80513c7 in Py_Main (argc=2, argv=0xbffff824) at main.c:271 #6 0x8050f56 in main (argc=2, argv=0xbffff824) at python.c:10 (gdb) The program is running. Exit anyway? (y or n) y Follow-Ups: Date: 2000-Aug-07 23:34 By: hooft Comment: Since today (compile.c 2.119) This no longer dumps core, but gives the new "SystemError: lost syntax error" error message. ------------------------------------------------------- Date: 2000-Aug-25 13:47 By: jhylton Comment: Is this bug now fixed? The most recent comment suggests it is. If so, please let me know and I'll close this report. ------------------------------------------------------- Date: 2000-Aug-25 15:45 By: tim_one Comment: Well, while raising SystemError is friendlier than a core dump, at heart they're both ways to spell "the compiler is *really* confused" -- we shouldn't ever raise SystemError. ------------------------------------------------------- Date: 2000-Aug-25 15:55 By: tim_one Comment: Note comment from compile.c: /* This could happen if someone called PyErr_Clear() after * an error was reported above. That's not supposed to * happen, but I just plugged one case and I'm not sure * there can't be others. In that case, raise SystemError * so that at least it gets reported instead dumping core. */ PyErr_SetString(PyExc_SystemError, "lost syntax error"); So we got an internal error going here all right. Can't reproduce under Windows, though. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110915&group_id=5470 From noreply@sourceforge.net Mon Aug 28 18:33:01 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 10:33:01 -0700 Subject: [Python-bugs-list] [Bug #112943] infinite recursion bug Message-ID: <200008281733.KAA14348@delerium.i.sourceforge.net> Bug #112943, was updated on 2000-Aug-28 08:40 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: None Priority: 9 Summary: infinite recursion bug Details: Hello! PythonWin crashes when trying to run the following code Hello! PythonWin 1.5.2 (build 132) crashes (on WinNT 4.0) on the following code. class X: def __init__(self,x): self.val = x def __add__(x,y): return X(x.val + y.val) def __radd__(x,y): return y + x if __name__ == '__main__': x = X(4) y = 3 + x Follow-Ups: Date: 2000-Aug-28 08:49 By: gvanrossum Comment: Hello! The example causes endless recursion on __radd__. (You should have said "return x+y" there.) Hello! It is still a bug in 2.0b1! Should be fixed. ------------------------------------------------------- Date: 2000-Aug-28 10:33 By: effbot Comment: footnote: with the current CVS version, this one raises a MemoryError (Stack overflow) -- at least on my Windows 95 box. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112943&group_id=5470 From noreply@sourceforge.net Mon Aug 28 19:52:42 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 11:52:42 -0700 Subject: [Python-bugs-list] [Bug #110688] Reuben Sumner: Py_REF_COUNT (PR#43) Message-ID: <200008281852.LAA17197@delerium.i.sourceforge.net> Bug #110688, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 3 Summary: Reuben Sumner: Py_REF_COUNT (PR#43) Details: Jitterbug-Id: 43 Submitted-By: Guido van Rossum Date: Fri, 30 Jul 1999 13:52:16 -0400 Version: None OS: None ------- Forwarded Message Date: Tue, 20 Jul 1999 10:53:34 +0300 From: Reuben Sumner To: guido@python.org Subject: Py_REF_COUNT I posted a message through DejaNews which didn't seem to propogate (at least it didn't reach here). Try the following in a Python with Py_REF_DEBUG but without Py_TRACE_REFS class C: def __init__(self): pass while 1: c=C() Stop it after a while and look at the reference count printed! Python is not actually using all that memory though. With Py_TRACE_REFS things are ok. I can't figure it out. The class instance dealloc routine is rather hairy. With Py_TRACE_REFS some code of mine is doing some really bizarre things but I would rather deal with one thing at a time. Python version is 1.5.2 (tried on at least two platforms, both using gcc) Many thanks, Reuben ------- End of Forwarded Message ==================================================================== Audit trail: Wed Aug 04 12:12:39 1999 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-28 11:52 By: jhylton Comment: This report is a bit too vague to be useful. I've queried the original poster to see if he is still having problems. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110688&group_id=5470 From noreply@sourceforge.net Tue Aug 29 04:43:54 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 20:43:54 -0700 Subject: [Python-bugs-list] [Bug #110650] python with-threads core-dumps (PR#342) Message-ID: <200008290343.UAA10516@bush.i.sourceforge.net> Bug #110650, was updated on 2000-Jul-31 14:10 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: python with-threads core-dumps (PR#342) Details: Jitterbug-Id: 342 Submitted-By: michael.exner@mrz.uni-magdeburg.de Date: Wed, 31 May 2000 09:43:38 -0400 (EDT) Version: 1.5.2 OS: hpux-11.00 When I compile python with threads python core-dumps: $ ./python pthread_mutex_init: Invalid argument Memory fault(coredump) without thread-support everything works fine I tried this with hpux-ansi-c and with gcc (2.95.2) but got the same result ==================================================================== Audit trail: Tue Jul 11 08:25:57 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-28 20:43 By: tim_one Comment: Note that the only call to pthread_mutex_init Python makes is in function PyThread_allocate_lock in file phread_pthread.h. If Python compiled at all, it's extremely unlikely that the first argument is in error. It's very likely that the second argument is in error, though: there were many imcompatible revisions of the pthreads std, and pthread_mutexattr_default is a macro conditionally defined near the top of the file. If this OS actually support pthreads, you have to figure out which *version* of pthreads it defines and arrange for config to define the *correct* one of the PY_PTHREAD_D4 PY_PTHREAD_D7 PY_PTHREAD_STD PY_PTHREAD_D6 symbols for your platform. Else disable threads entirely. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110650&group_id=5470 From noreply@sourceforge.net Tue Aug 29 14:57:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 06:57:34 -0700 Subject: [Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX Message-ID: <200008291357.GAA30699@bush.i.sourceforge.net> Bug #113037, was updated on 2000-Aug-29 06:57 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: auotconf/build problems on HP-UX Details: From: Mike Romberg To: jeremy@beopen.com Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT) >>>>> " " == Jeremy Hylton writes: > Mike, I can't reproduce the bug you report. Can you check > against the current CVS and see if it still has the problem? > It may be that the bug has been fixed since you reported it. Here is a followup. Using the CVS tree from last friday, this is what I get: 1 - Default install seems to enable threads and cycle-gc. This has core dumps. 2 - --without-thread. Dumps core as well. 3 - --without-cycle-gc --without-thread. This has some kind of problem with the importer. It breaks with 'from foo import *'. 4 - I attempted to build this CVS version on HP-UX so that I might run purify with it. The CVS version did not build on HP-UX. The build fails with a 'no rule to make dynload-hpux' (or something really close). I removed this object file from the Makefile. But the build failed later on with undeclared functions. I'm still going to try using purify with python-1.6b1 (which did compile on HP-UX). So, I tried getting a new CVS version this morning. This core dumps right off the bat (compiled with --without-cycle-gc --without-thread). #0 do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353 #1 0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, n=4) at modsupport.c:223 #2 0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:247 #3 0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744) at modsupport.c:415 #4 0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390 #5 0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1630 #6 0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288) at ceval.c:313 #7 0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", co=0x8f4c1b8, pathname=0x8a203ea "") at import.c:497 #8 0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site") at import.c:1387 #9 0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, buf=0xbfffe914 "site", type=7) at import.c:1232 #10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", fullname=0xbfffeda4 "site") at import.c:1727 #11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0) at import.c:1583 #12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at import.c:1434 #13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, locals=0x0, fromlist=0x0) at import.c:1475 #14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408 #15 0x86a014b in initsite () at pythonrun.c:429 #16 0x869fdca in Py_Initialize () at pythonrun.c:166 #17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22 For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470 From noreply@sourceforge.net Tue Aug 29 15:01:53 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 07:01:53 -0700 Subject: [Python-bugs-list] [Bug #112944] Second import of module succeeds even if first import failed Message-ID: <200008291401.HAA30883@bush.i.sourceforge.net> Bug #112944, was updated on 2000-Aug-28 09:03 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: Second import of module succeeds even if first import failed Details: The second import of a library that failed the first time does not re-initialize the module, and returns a reference to the uninitialized module: >>> import cPickle Traceback (most recent call last): File "", line 1, in ? ImportError: No module named copy_reg >>> ^P File "", line 1 ^ SyntaxError: invalid syntax >>> import cPickle >>> Subsequent use of the uninitialized module crashes the interpreter: >>> cPickle.Pickler() Segmentation fault (core dumped) (and it happens the same way in scripts.) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112944&group_id=5470 From mal@lemburg.com Tue Aug 29 15:02:25 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 29 Aug 2000 16:02:25 +0200 Subject: [Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX References: <200008291357.GAA30699@bush.i.sourceforge.net> Message-ID: <39ABC271.75E76487@lemburg.com> noreply@sourceforge.net wrote: > > Bug #113037, was updated on 2000-Aug-29 06:57 > Here is a current snapshot of the bug. > > Project: Python > Category: Build > Status: Open > Resolution: None > Bug Group: Platform-specific > Priority: 7 > Summary: auotconf/build problems on HP-UX > > Details: From: Mike Romberg > To: jeremy@beopen.com > Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net) > Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT) > > >>>>> " " == Jeremy Hylton writes: > > > Mike, I can't reproduce the bug you report. Can you check > > against the current CVS and see if it still has the problem? > > It may be that the bug has been fixed since you reported it. > > Here is a followup. Using the CVS tree from last friday, this is > what I get: > > 1 - Default install seems to enable threads and cycle-gc. This has > core dumps. > > 2 - --without-thread. Dumps core as well. > > 3 - --without-cycle-gc --without-thread. This has some kind of > problem with the importer. It breaks with 'from foo import *'. > > 4 - I attempted to build this CVS version on HP-UX so that I might > run purify with it. The CVS version did not build on HP-UX. > The build fails with a 'no rule to make dynload-hpux' (or > something really close). I removed this object file from the > Makefile. But the build failed later on with undeclared > functions. I'm still going to try using purify with > python-1.6b1 (which did compile on HP-UX). > > So, I tried getting a new CVS version this morning. This core dumps > right off the bat (compiled with --without-cycle-gc --without-thread). > > #0 do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353 > #1 0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, > n=4) at modsupport.c:223 > #2 0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) > at modsupport.c:247 > #3 0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744) > at modsupport.c:415 > #4 0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390 > #5 0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, > locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, > defcount=0, owner=0x0) at ceval.c:1630 > #6 0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, > locals=0x8f4c288) at ceval.c:313 > #7 0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", > co=0x8f4c1b8, pathname=0x8a203ea "") at import.c:497 > #8 0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site") > at import.c:1387 Why does Python try to import site as frozen module ? Could it be that you have frozen site.py using a pre-2.0 Python version and that this causes the core dump ? > #9 0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, > buf=0xbfffe914 "site", type=7) at import.c:1232 > #10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", > fullname=0xbfffeda4 "site") at import.c:1727 > #11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, > p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0) > at import.c:1583 > #12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, > fromlist=0x0) at import.c:1434 > #13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, > locals=0x0, fromlist=0x0) at import.c:1475 > #14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408 > #15 0x86a014b in initsite () at pythonrun.c:429 > #16 0x869fdca in Py_Initialize () at pythonrun.c:166 > #17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22 > > For detailed info, follow this link: > http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470 > > _______________________________________________ > Python-bugs-list maillist - Python-bugs-list@python.org > http://www.python.org/mailman/listinfo/python-bugs-list -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From noreply@sourceforge.net Tue Aug 29 16:51:25 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 08:51:25 -0700 Subject: [Python-bugs-list] [Bug #113047] test_poll fails on FreeBSD 4.1 Message-ID: <200008291551.IAA02492@bush.i.sourceforge.net> Bug #113047, was updated on 2000-Aug-29 08:51 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: test_poll fails on FreeBSD 4.1 Details: We have a FreeBSD 4.1 system at BeOpen now, and when I build Python all tests succeed except for test_poll. The error is this assert in test_poll1(): assert len(buf) == MSG_LEN When I add a print statement, len(buf) is zero. Any suggestion as to what I should do next? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113047&group_id=5470 From noreply@sourceforge.net Tue Aug 29 17:12:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 09:12:34 -0700 Subject: [Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX Message-ID: <200008291612.JAA03257@bush.i.sourceforge.net> Bug #113037, was updated on 2000-Aug-29 06:57 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: auotconf/build problems on HP-UX Details: From: Mike Romberg To: jeremy@beopen.com Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT) >>>>> " " == Jeremy Hylton writes: > Mike, I can't reproduce the bug you report. Can you check > against the current CVS and see if it still has the problem? > It may be that the bug has been fixed since you reported it. Here is a followup. Using the CVS tree from last friday, this is what I get: 1 - Default install seems to enable threads and cycle-gc. This has core dumps. 2 - --without-thread. Dumps core as well. 3 - --without-cycle-gc --without-thread. This has some kind of problem with the importer. It breaks with 'from foo import *'. 4 - I attempted to build this CVS version on HP-UX so that I might run purify with it. The CVS version did not build on HP-UX. The build fails with a 'no rule to make dynload-hpux' (or something really close). I removed this object file from the Makefile. But the build failed later on with undeclared functions. I'm still going to try using purify with python-1.6b1 (which did compile on HP-UX). So, I tried getting a new CVS version this morning. This core dumps right off the bat (compiled with --without-cycle-gc --without-thread). #0 do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353 #1 0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, n=4) at modsupport.c:223 #2 0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:247 #3 0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744) at modsupport.c:415 #4 0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390 #5 0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1630 #6 0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288) at ceval.c:313 #7 0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", co=0x8f4c1b8, pathname=0x8a203ea "") at import.c:497 #8 0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site") at import.c:1387 #9 0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, buf=0xbfffe914 "site", type=7) at import.c:1232 #10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", fullname=0xbfffeda4 "site") at import.c:1727 #11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0) at import.c:1583 #12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at import.c:1434 #13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, locals=0x0, fromlist=0x0) at import.c:1475 #14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408 #15 0x86a014b in initsite () at pythonrun.c:429 #16 0x869fdca in Py_Initialize () at pythonrun.c:166 #17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22 Follow-Ups: Date: 2000-Aug-29 09:12 By: jhylton Comment: More details from comp.lang.python: From: Philipp Jocham Subject: Re: need help with build on HP-UX Newsgroups: comp.lang.python Date: Tue, 29 Aug 2000 11:23:25 GMT Message-ID: Python-1.6b1 on HP-UX 11.00 build with gcc-2.8.1 % ./configure --with-threads [...] checking for --with-thread... yes checking for mach/cthreads.h... no checking for pth_init in -lpth... no checking for pthread_create in -lpthread... no checking for pthread_detach... no checking for kernel/OS.h... no checking for pthread_create in -lpthreads... no checking for pthread_create in -lc_r... no checking for __d6_pthread_create in -lthread... no checking for pthread_create in -lcma... yes [...] % make % make test yields [...] PYTHONPATH= ./python -tt ./Lib/test/regrtest.py pthread_mutex_init: Invalid argument sh: 5019 Memory fault(coredump) *** Error exit code 139 (ignored) I've experienced a similar problem with python-1.5.2 see http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=110665 The problem is the same. The function pthread_create is a macro in sys/pthread.h and pointing to __pthread_create_system. Finally pthread_create is detected in /usr/lib/libcma.a, which doesn't have a compatible pthread_mutex_init function. Hacking the Makefiles (after running configure) by changing the LIBS= lines from LIBS= -lnet -lnsl -ldld -lcma to LIBS= -lnet -lnsl -ldld -lpthread -lcl links the object-files against the pthread library. This solution has worked for 1.5.2 and runs at least all tests correctly for 1.6b1 A solution might be to add a test for __pthread_create_system in /usr/lib/libpthread.a in the configure.in script. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470 From noreply@sourceforge.net Tue Aug 29 17:15:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 09:15:02 -0700 Subject: [Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX Message-ID: <200008291615.JAA03391@bush.i.sourceforge.net> Bug #113037, was updated on 2000-Aug-29 06:57 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: auotconf/build problems on HP-UX Details: From: Mike Romberg To: jeremy@beopen.com Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT) >>>>> " " == Jeremy Hylton writes: > Mike, I can't reproduce the bug you report. Can you check > against the current CVS and see if it still has the problem? > It may be that the bug has been fixed since you reported it. Here is a followup. Using the CVS tree from last friday, this is what I get: 1 - Default install seems to enable threads and cycle-gc. This has core dumps. 2 - --without-thread. Dumps core as well. 3 - --without-cycle-gc --without-thread. This has some kind of problem with the importer. It breaks with 'from foo import *'. 4 - I attempted to build this CVS version on HP-UX so that I might run purify with it. The CVS version did not build on HP-UX. The build fails with a 'no rule to make dynload-hpux' (or something really close). I removed this object file from the Makefile. But the build failed later on with undeclared functions. I'm still going to try using purify with python-1.6b1 (which did compile on HP-UX). So, I tried getting a new CVS version this morning. This core dumps right off the bat (compiled with --without-cycle-gc --without-thread). #0 do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353 #1 0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, n=4) at modsupport.c:223 #2 0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:247 #3 0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744) at modsupport.c:415 #4 0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390 #5 0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1630 #6 0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288) at ceval.c:313 #7 0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", co=0x8f4c1b8, pathname=0x8a203ea "") at import.c:497 #8 0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site") at import.c:1387 #9 0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, buf=0xbfffe914 "site", type=7) at import.c:1232 #10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", fullname=0xbfffeda4 "site") at import.c:1727 #11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0) at import.c:1583 #12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at import.c:1434 #13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, locals=0x0, fromlist=0x0) at import.c:1475 #14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408 #15 0x86a014b in initsite () at pythonrun.c:429 #16 0x869fdca in Py_Initialize () at pythonrun.c:166 #17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22 Follow-Ups: Date: 2000-Aug-29 09:12 By: jhylton Comment: More details from comp.lang.python: From: Philipp Jocham Subject: Re: need help with build on HP-UX Newsgroups: comp.lang.python Date: Tue, 29 Aug 2000 11:23:25 GMT Message-ID: Python-1.6b1 on HP-UX 11.00 build with gcc-2.8.1 % ./configure --with-threads [...] checking for --with-thread... yes checking for mach/cthreads.h... no checking for pth_init in -lpth... no checking for pthread_create in -lpthread... no checking for pthread_detach... no checking for kernel/OS.h... no checking for pthread_create in -lpthreads... no checking for pthread_create in -lc_r... no checking for __d6_pthread_create in -lthread... no checking for pthread_create in -lcma... yes [...] % make % make test yields [...] PYTHONPATH= ./python -tt ./Lib/test/regrtest.py pthread_mutex_init: Invalid argument sh: 5019 Memory fault(coredump) *** Error exit code 139 (ignored) I've experienced a similar problem with python-1.5.2 see http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=110665 The problem is the same. The function pthread_create is a macro in sys/pthread.h and pointing to __pthread_create_system. Finally pthread_create is detected in /usr/lib/libcma.a, which doesn't have a compatible pthread_mutex_init function. Hacking the Makefiles (after running configure) by changing the LIBS= lines from LIBS= -lnet -lnsl -ldld -lcma to LIBS= -lnet -lnsl -ldld -lpthread -lcl links the object-files against the pthread library. This solution has worked for 1.5.2 and runs at least all tests correctly for 1.6b1 A solution might be to add a test for __pthread_create_system in /usr/lib/libpthread.a in the configure.in script. ------------------------------------------------------- Date: 2000-Aug-29 09:15 By: jhylton Comment: Another suggestion from comp.lang.python From: Michael Maul Subject: Re: need help with build on HP-UX Newsgroups: comp.lang.python Date: Tue, 29 Aug 2000 10:33:05 -0400 Message-ID: <39ABC9A0.C584B210@nortelnetworks.com> Goto link below for instructions and patches for building python 152 with threads on hpux 10.20 with DCE threads http://memaul.tripod.com/index.html ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470 From noreply@sourceforge.net Tue Aug 29 17:24:03 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 09:24:03 -0700 Subject: [Python-bugs-list] [Bug #113047] test_poll fails on FreeBSD 4.1 Message-ID: <200008291624.JAA03718@bush.i.sourceforge.net> Bug #113047, was updated on 2000-Aug-29 08:51 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: test_poll fails on FreeBSD 4.1 Details: We have a FreeBSD 4.1 system at BeOpen now, and when I build Python all tests succeed except for test_poll. The error is this assert in test_poll1(): assert len(buf) == MSG_LEN When I add a print statement, len(buf) is zero. Any suggestion as to what I should do next? Follow-Ups: Date: 2000-Aug-29 09:24 By: akuchling Comment: What the test is doing is creating a bunch of pipes, writing the string MSG to them, and then reading them back. test_poll1() has just picked a random pipe that's ready for reading, and tried to read MSG_LEN bytes, but instead it got back the empty string. Print the contents of the 'ready' list and of the 'ready_readers' list constructed from it; maybe find_ready_readers in the test module is buggy. (Or maybe this behaviour is legal for some reason, and the assertion is too stringent.) I could get a log in on the FreeBSD machine at SourceForge and look into this. The test_poll1() function was contributed by Jeremy, BTW, so if he has access to your FreeBSD machine, he could also look into it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113047&group_id=5470 From noreply@sourceforge.net Tue Aug 29 18:00:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 10:00:44 -0700 Subject: [Python-bugs-list] [Bug #113047] test_poll fails on FreeBSD 4.1 Message-ID: <200008291700.KAA31709@delerium.i.sourceforge.net> Bug #113047, was updated on 2000-Aug-29 08:51 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: None Bug Group: Platform-specific Priority: 5 Summary: test_poll fails on FreeBSD 4.1 Details: We have a FreeBSD 4.1 system at BeOpen now, and when I build Python all tests succeed except for test_poll. The error is this assert in test_poll1(): assert len(buf) == MSG_LEN When I add a print statement, len(buf) is zero. Any suggestion as to what I should do next? Follow-Ups: Date: 2000-Aug-29 09:24 By: akuchling Comment: What the test is doing is creating a bunch of pipes, writing the string MSG to them, and then reading them back. test_poll1() has just picked a random pipe that's ready for reading, and tried to read MSG_LEN bytes, but instead it got back the empty string. Print the contents of the 'ready' list and of the 'ready_readers' list constructed from it; maybe find_ready_readers in the test module is buggy. (Or maybe this behaviour is legal for some reason, and the assertion is too stringent.) I could get a log in on the FreeBSD machine at SourceForge and look into this. The test_poll1() function was contributed by Jeremy, BTW, so if he has access to your FreeBSD machine, he could also look into it. ------------------------------------------------------- Date: 2000-Aug-29 10:00 By: gvanrossum Comment: Fixed in record time by Andrew. Thanks, Andrew! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113047&group_id=5470 From noreply@sourceforge.net Tue Aug 29 20:09:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 12:09:02 -0700 Subject: [Python-bugs-list] [Bug #110915] compiler core-dumps on illegal continue Message-ID: <200008291909.MAA10085@bush.i.sourceforge.net> Bug #110915, was updated on 2000-Aug-02 05:13 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: compiler core-dumps on illegal continue Details: On my RedHat 6.2 system, the latest CVS version of python still dumps core on the following script: ------------------------------------------------- def gentheta(): while 1: try: continue finally: pass def genkappa(): if whatsmounted!='crystal': mountcrystal() while 1: if not inhibitmake: projtls.moveoutofway('kappa',dirok=1) os.mkdir('kappa') os.chdir('kappa') try: announce("Testing Kappa zero-point") # Use the detalign.vic produced by the dx calibration dal=os.path.join('..','dx','detalign.vic') if os.path.exists(dal): print "NOTE: Using detalign.vic from dx calibration" filecopy(dal,'detalign.vic') if not inhibitmake: status=os.system('calkappa make') else: status=os.system('calkappa') if status!=0: beeper.on() answer=command.question(root,'Calkappa Warnings',text='Calkappa issued some warnings and/or errors.\nPlease check what they are, and tell me what to do', strings=("Ignore them","Retry calkappa","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break if os.path.exists('instruct.txt'): beeper.on() answer=command.fixedfontquestion( root,'Kappa missetting needs correction', text=open('instruct.txt').read(), strings=("I have now done this","I'm ignoring this for now","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break else: # No instructions means no correction required break finally: os.chdir('..') ------------------------------------------- Any simplification in the second function makes the compiler report the "SyntaxError: continue not properly in loop" in line 4. Stack trace: ------------------------------------------- no203[140]~%3% gdb =python GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run x.py Starting program: /usr/local/nonius/bin/python x.py Program received signal SIGSEGV, Segmentation fault. PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 153 if (PyClass_Check(type)) { (gdb) where #0 PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 #1 0x8063901 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:672 #2 0x80638d6 in PyErr_Print () at pythonrun.c:663 #3 0x806368b in PyRun_SimpleFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:574 #4 0x806335d in PyRun_AnyFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:458 #5 0x80513c7 in Py_Main (argc=2, argv=0xbffff824) at main.c:271 #6 0x8050f56 in main (argc=2, argv=0xbffff824) at python.c:10 (gdb) The program is running. Exit anyway? (y or n) y Follow-Ups: Date: 2000-Aug-07 23:34 By: hooft Comment: Since today (compile.c 2.119) This no longer dumps core, but gives the new "SystemError: lost syntax error" error message. ------------------------------------------------------- Date: 2000-Aug-25 13:47 By: jhylton Comment: Is this bug now fixed? The most recent comment suggests it is. If so, please let me know and I'll close this report. ------------------------------------------------------- Date: 2000-Aug-25 15:45 By: tim_one Comment: Well, while raising SystemError is friendlier than a core dump, at heart they're both ways to spell "the compiler is *really* confused" -- we shouldn't ever raise SystemError. ------------------------------------------------------- Date: 2000-Aug-25 15:55 By: tim_one Comment: Note comment from compile.c: /* This could happen if someone called PyErr_Clear() after * an error was reported above. That's not supposed to * happen, but I just plugged one case and I'm not sure * there can't be others. In that case, raise SystemError * so that at least it gets reported instead dumping core. */ PyErr_SetString(PyExc_SystemError, "lost syntax error"); So we got an internal error going here all right. Can't reproduce under Windows, though. ------------------------------------------------------- Date: 2000-Aug-29 12:09 By: jhylton Comment: Here's a stack trace showing the next PyErr_Clear call after SyntaxError is set. Looks like it could be a GC bug. #0 PyErr_Clear () at ../../Python/errors.c:225 #1 0x8098c1b in collect (young=0x80c9960, old=0x80c996c) at ../../Modules/gcmodule.c:447 #2 0x8098d1c in collect_generations () at ../../Modules/gcmodule.c:479 #3 0x8098d5f in _PyGC_Insert (op=0x811897c) at ../../Modules/gcmodule.c:498 #4 0x807ec14 in PyTuple_New (size=2) at ../../Objects/tupleobject.c:96 #5 0x8063d37 in do_mktuple (p_format=0xbffff1c8, p_va=0xbffff1cc, endchar=41, n=2) at ../../Python/modsupport.c:220 #6 0x8063e13 in do_mkvalue (p_format=0xbffff1c8, p_va=0xbffff1cc) at ../../Python/modsupport.c:247 #7 0x806404d in Py_VaBuildValue (format=0x80ab8c0 "(OO)", va=0xbffff1ec) at ../../Python/modsupport.c:415 #8 0x8063feb in Py_BuildValue (format=0x80ab8c0 "(OO)") at ../../Python/modsupport.c:390 #9 0x805905d in com_add (c=0xbffff7bc, list=0x811738c, dict=0x8116eb4, v=0x8118948) at ../../Python/compile.c:645 #10 0x805912d in com_addconst (c=0xbffff7bc, v=0x8118948) at ../../Python/compile.c:674 #11 0x805a1ca in com_argument (c=0xbffff7bc, n=0x81206b8, pkeywords=0xbffff270) at ../../Python/compile.c:1299 #12 0x805a2b9 in com_call_function (c=0xbffff7bc, n=0x811fd94) at ../../Python/compile.c:1332 #13 0x805a78a in com_apply_trailer (c=0xbffff7bc, n=0x811fd08) at ../../Python/compile.c:1515 #14 0x805a830 in com_power (c=0xbffff7bc, n=0x811fc80) at ../../Python/compile.c:1543 #15 0x805a8a7 in com_factor (c=0xbffff7bc, n=0x811fc60) at ../../Python/compile.c:1564 #16 0x805a8c1 in com_term (c=0xbffff7bc, n=0x811fc40) at ../../Python/compile.c:1574 #17 0x805a98d in com_arith_expr (c=0xbffff7bc, n=0x811fc20) at ../../Python/compile.c:1603 #18 0x805aa39 in com_shift_expr (c=0xbffff7bc, n=0x811fc00) at ../../Python/compile.c:1629 #19 0x805aae9 in com_and_expr (c=0xbffff7bc, n=0x811fbe0) at ../../Python/compile.c:1655 #20 0x805ab81 in com_xor_expr (c=0xbffff7bc, n=0x811fbc0) at ../../Python/compile.c:1677 #21 0x805ac19 in com_expr (c=0xbffff7bc, n=0x811fba0) at ../../Python/compile.c:1699 #22 0x805ade4 in com_comparison (c=0xbffff7bc, n=0x811fb80) at ../../Python/compile.c:1753 #23 0x805af31 in com_not_test (c=0xbffff7bc, n=0x811fb60) at ../../Python/compile.c:1828 #24 0x805af9e in com_and_test (c=0xbffff7bc, n=0x811fb40) at ../../Python/compile.c:1845 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110915&group_id=5470 From noreply@sourceforge.net Tue Aug 29 22:12:34 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 14:12:34 -0700 Subject: [Python-bugs-list] [Bug #110601] expert on extension modules and multiple interpreters? (PR#125) Message-ID: <200008292112.OAA08673@delerium.i.sourceforge.net> Bug #110601, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: expert on extension modules and multiple interpreters? (PR#125) Details: Jitterbug-Id: 125 Submitted-By: Nikolas Kauer Date: Tue, 9 Nov 1999 18:43:09 -0600 (CST) Version: None OS: None Dear Guido, (please read first paragraph) I discovered a Python problem that so far nobody could really explain, since a precise explanation requires in-depth knowledge about the internals of the Python interpreter. I HAVE DONE MY HOMEWORK and have posted this message to various mailing lists including comp.lang.python, python-help@python.org and pyapache-devel@msg.com.mx and communicated with several people individually, getting some guesses (appended after the problem description), but no competent answer, yet. I'm sure you know somebody who could provide that answer, and would appreciate it if you could FORWARD THIS MESSAGE to such a person. Best regards, Nikolas PS I'm sure you heard this a thousand times, nevertheless I like Python and enjoy programming in Python. I think it's a beautifully designed programming language. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I run the following test script on Apache-1.3.6/PyApache-4.19 on Linux 2.2.5 (RedHat 6.0) with only one httpd child and the module mxDateTime compiled into Python/PyApache, so there is no dynamic loading of a shared library. ------------------------------------------------------------ print "Content-type: text/plain" print print import sys, traceback # just checking ... if not sys.modules.has_key('mxDateTime'): print 'No module mxDateTime in sys.modules' print import mxDateTime print "sys.modules['mxDateTime'] = ", sys.modules['mxDateTime'] print "mxDateTime.__dict__['now'] = ", mxDateTime.__dict__['now'] print print "calling mxDateTime.now() gives:", try: print mxDateTime.now() except: print traceback.print_exc(file=sys.stdout) -------------------------------------------------------------- First time http://localhost/mytest.py gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = mxDateTime.__dict__['now'] = calling mxDateTime.now() gives: 1999-10-28 18:28:49.75 ******************************* And again http://localhost/mytest.py now gives ******************************* No module mxDateTime in sys.modules sys.modules['mxDateTime'] = mxDateTime.__dict__['now'] = calling mxDateTime.now() gives: Traceback (innermost last): File "/local/web/alpha/docroot/mytest.py", line 16, in ? print mxDateTime.now() TypeError: call of non-function (type None) ******************************* After that experience, I eliminated all dependencies on module DateTime/mxDateTime in my Python code, but now I get the same error whenever something in module MySQLdb is accessed for the second time ... The mxDateTime author Marc Lemburg writes: "[...] indicates that PyApache (or perhaps the Python finalizer) has cleared the module's namespace... which is bad, since extension modules can typically only initialize themselves *once*." Marc writes further: "[T]his is really odd: the 'now' symbol still refers to the existing function while the module seems to return None as attribute." The PyApache coordinator Lele Gaifax writes: "I can confirm that the problem lives in the cleanup mechanism. Python clears up its dictionaries, and doesn't allow a reinit, as Marc pointed out. This is not a PyApache fault: you can get the very same result running the pysrv demo [...]. In fact, every use of such modules mixed to multiple interpreters should cause the problem." Apparently, the fact that a module works with regular Python does not guarantee that it also works with PyApache (or pysrv). Lele Gaifax writes: "[...]I cannot see a way out, if not digging in Python's internals. [D]oes someone know if the problem has been raised before in the Python community?" Please, could someone with Python internals expertise explain this issue? How can I tell in advance if an extension module will work with PyApache? Is it possible to trick Python into cleanly re-initializing a module? Is there any hope that I can run my existing Web site with the Python interpreter embedded into Apache's httpd? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ More insights from this past week: Lele Gaifax writes: "Well, I seems to have tracked it down to the cache you use on Python's time module. I changed the function mxDateTime_now, where's the only reference to that module, to use `PyImport_AddModule ("time")' instead and extracting the dictionary from its result instead from Python_time_module, that I left alone. That function returns a borrowed reference to the module object, *provided* it is already loaded. Since this is done at mxDateTime's initialization, this is probably safe, but it needs to be checked... Anyway, so patched the module does not break PyApache, [...]" Marc Lemburg replies: "That's interesting: the time module's namespace is probably cleared during the Fini code stage. This would change the interpretation of the error. What you see is the error produced by the internals of the now() function and not related to the mxDateTime module namespace itself. Since time.time is the only function I really use from the Python time module perhaps caching only the function would do the trick. BTW, when finalization occurrs, is mxDateTime_Cleanup() being called ? It should reset the global reference to the time module (at least that's what my current code does): [code] Something else I could do is move time module lookup from the initmxDateTime() function into now() itself in case that helps. [...] I would guess that the setup mxODBC + mxDateTime has the same problems related to mxODBC holding a reference to mxDateTime." Any help in form of diagnostics, explanations and suggestions would be greatly appreciated. Nikolas ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Some ideas from python-help@python.org: Mark Hammond writes: "If I understand the problem correct, it is simply that Python can not handle multiple Py_Init()/Py_Finalize() calls. Doing a Py_Finalize() cleans things up, but another Py_Init() can not restore everything back to a working state. I agree this is a problem, and it has ben brought up before. I suffer the same problem with the COM extensions. Ideally this needs to be fixed properly, but it is not trivial to do so - the entire module init process would need to be re-thought. The only solution I can think of is to get Apache to never finalize Python. Of course, I may be completely off-track here..." Martin von Loewis writes: "I think the problem is different. PyApache does *not* invoke Py_Finalize(*), but Py_EndInterpreter. This does PyImport_Cleanup, then PyInterpreterState_Delete. This is where I got stuck: The PyImport_Cleanup iterates over the interpreter-state's module list, which is then cleared, and completely discarded. I did not actually find the place where state is preserved across interpreters, so the problem can't possibly happen :-> (*) Of course, Apache eventually does Py_Finalize, when the whole server is shut down. Each individual CGI only goes through Py_NewInterpreter/Py_EndInterpreter." ==================================================================== Audit trail: Fri Dec 03 10:21:06 1999 guido changed notes Fri Dec 03 10:21:07 1999 guido moved from incoming to open Fri Dec 03 10:21:47 1999 guido changed notes Follow-Ups: Date: 2000-Aug-13 23:31 By: mhammond Comment: Assigning to MAL - it involves mxODBC and Apache on a Linux box, so surely he is more qualified :-) I'm inclined to mark this is irreproducible, but maybe Marc has had further insights. ------------------------------------------------------- Date: 2000-Aug-14 03:31 By: lemburg Comment: The problem you describe is an artifact of the way mxDateTime tries to reuse the time.time() API available through the standard Python time module. I think I have fixed the problem in my latest version. If you're interested I can email you a pre-release copy to test it against PyApache. ------------------------------------------------------- Date: 2000-Aug-29 14:12 By: lemburg Comment: This was a bug in mxDateTime < 1.3.0 and will be hopefully be fixed with the new upcoming relase 1.4.0. A pre-release is available at: http://starship.python.net/~lemburg/mxDateTime-1.4.0-prerelease.zip in case someone wants to test it. The bug doesn't have anything to do with Python internals, so I'm closing it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110601&group_id=5470 From noreply@sourceforge.net Tue Aug 29 22:30:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 14:30:58 -0700 Subject: [Python-bugs-list] [Bug #112944] Partially initialized cPickle dumps core Message-ID: <200008292130.OAA15610@bush.i.sourceforge.net> Bug #112944, was updated on 2000-Aug-28 09:03 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: Partially initialized cPickle dumps core Details: The second import of a library that failed the first time does not re-initialize the module, and returns a reference to the uninitialized module: >>> import cPickle Traceback (most recent call last): File "", line 1, in ? ImportError: No module named copy_reg >>> ^P File "", line 1 ^ SyntaxError: invalid syntax >>> import cPickle >>> Subsequent use of the uninitialized module crashes the interpreter: >>> cPickle.Pickler() Segmentation fault (core dumped) (and it happens the same way in scripts.) Follow-Ups: Date: 2000-Aug-29 14:30 By: gvanrossum Comment: The stated problem is not a bug but documented behavior. However the fact that a partially initialized cPickle dumps core is a cPickle bug. I'll change the topic and see if I can get the cPickle author (Jim Fulton) to look at this. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112944&group_id=5470 From noreply@sourceforge.net Wed Aug 30 04:31:59 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 20:31:59 -0700 Subject: [Python-bugs-list] [Bug #110778] pyport.h compile error on windows Message-ID: <200008300331.UAA21808@delerium.i.sourceforge.net> Bug #110778, was updated on 2000-Aug-01 09:01 Here is a current snapshot of the bug. Project: Python Category: Build Status: Closed Resolution: Fixed Bug Group: None Priority: 7 Summary: pyport.h compile error on windows Details: pyport.h contains the following line, previously from myselect.h #define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */ On windows, NBBY is not defined (Im not sure who is supposed to define it). myselect.h was never included on windows, so this had never previously been a problem Follow-Ups: Date: 2000-Aug-02 02:32 By: htrd Comment: This is fixed in CVS revision 2.10 ------------------------------------------------------- Date: 2000-Aug-29 20:31 By: tim_one Comment: Like the man said, this was fixed a long time ago. Closed it. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110778&group_id=5470 From noreply@sourceforge.net Wed Aug 30 05:51:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 21:51:23 -0700 Subject: [Python-bugs-list] [Bug #111481] os.stat() doesn't return st_rdev Message-ID: <200008300451.VAA24607@delerium.i.sourceforge.net> Bug #111481, was updated on 2000-Aug-09 06:38 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: os.stat() doesn't return st_rdev Details: The call os.stat() returns the fields st_mode, st_ino, st_nlink, st_uid, st_gid, st_size, st_atime, st_mtime st_ctime from "struct stat". To be able to explore device nodes on a linux system the field st_rdev needed as the major and minor device number is stored in this field. It would be nice if it could be added as an extra element in the tuple returned by os.stat, os.lstat etc. Follow-Ups: Date: 2000-Aug-29 21:51 By: fdrake Comment: We could add an additional element to the end with the st_rdev value, but I'm not convinced that's really the right approach; some other platform that defines another field could get that added at the end of the return tuple, and the the 11th position would have incompatible values. The "right" solution may be to create a new function (nstat?) that returns either a dictionary or other object that has entries for all the fields (using None for fields a platform doesn't provide values for). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111481&group_id=5470 From noreply@sourceforge.net Wed Aug 30 05:57:15 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 21:57:15 -0700 Subject: [Python-bugs-list] [Bug #113091] ExtensionClass should be in the core Message-ID: <200008300457.VAA24805@delerium.i.sourceforge.net> Bug #113091, was updated on 2000-Aug-29 21:57 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: ExtensionClass should be in the core Details: ExtensionClass, or something like it, should be part of the core interpreter. Such a facility would be used by builders of large sets of extensions to help manage internal type relationships. The Gtk+/Gnome extensions are already moving to ExtensionClass, and James Henstridge (the author) has indicated that he'd like to see better integration. Perhaps for 2.1? For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113091&group_id=5470 From noreply@sourceforge.net Wed Aug 30 05:59:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 21:59:18 -0700 Subject: [Python-bugs-list] [Bug #111203] 1.6b1 build (docs?) pyexpat problem on Windows Message-ID: <200008300459.VAA24938@delerium.i.sourceforge.net> Bug #111203, was updated on 2000-Aug-06 11:36 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: 1.6b1 build (docs?) pyexpat problem on Windows Details: pyexpat is not documented as one of those subprojects needing external software, but apparently it is one; it needs xmlparse and xmltok, .h and .lib to build and .dll to run. The docs don't mention where to get those from, but I had them around (from a Perl site build...) and feeding them to the Python 1.6b1 build fixed it. So I think it's just a doc-bug. Alex Follow-Ups: Date: 2000-Aug-29 21:59 By: fdrake Comment: What documentation is there on this? Sounds like something needs to change in the Windows README file; not sure. Tim, you're the Windows guy. Fix it. ;) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111203&group_id=5470 From noreply@sourceforge.net Wed Aug 30 06:21:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 29 Aug 2000 22:21:37 -0700 Subject: [Python-bugs-list] [Bug #111203] 1.6b1 build (docs?) pyexpat problem on Windows Message-ID: <200008300521.WAA31422@bush.i.sourceforge.net> Bug #111203, was updated on 2000-Aug-06 11:36 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: 1.6b1 build (docs?) pyexpat problem on Windows Details: pyexpat is not documented as one of those subprojects needing external software, but apparently it is one; it needs xmlparse and xmltok, .h and .lib to build and .dll to run. The docs don't mention where to get those from, but I had them around (from a Perl site build...) and feeding them to the Python 1.6b1 build fixed it. So I think it's just a doc-bug. Alex Follow-Ups: Date: 2000-Aug-29 21:59 By: fdrake Comment: What documentation is there on this? Sounds like something needs to change in the Windows README file; not sure. Tim, you're the Windows guy. Fix it. ;) ------------------------------------------------------- Date: 2000-Aug-29 22:21 By: tim_one Comment: Assigned to Guido, because last I heard 1.6 was frozen, and he's got the 1.6 Windows build setup anyway. The docs here were extensively rewritten for 2.0, and the complaint here doesn't exist there anymore. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111203&group_id=5470 From noreply@sourceforge.net Wed Aug 30 08:39:36 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 00:39:36 -0700 Subject: [Python-bugs-list] [Bug #110624] float("1.0e-309") inconsistency on win32 (PR#245) Message-ID: <200008300739.AAA03431@bush.i.sourceforge.net> Bug #110624, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: Remind Bug Group: None Priority: 5 Summary: float("1.0e-309") inconsistency on win32 (PR#245) Details: Jitterbug-Id: 245 Submitted-By: sde@recombinant.demon.co.uk Date: Wed, 22 Mar 2000 16:13:26 -0500 (EST) Version: 1.5.2 OS: win32 #! /usr/bin/python # Inconsistent behaviour. # Python 1.5.2 win32 fails the second print (why not both?) # other versions print both expressions # Ok Python 1.5.2 on SuSE Linux 6.3 # Ok JPython 1.1 on java1.1.7B # Partial failure Python 1.5.2 win32 print eval("float(1.0e-309)") print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 ==================================================================== Audit trail: Fri Mar 24 16:42:36 2000 guido changed notes Fri Mar 24 16:42:36 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Thu, 23 Mar 2000 01:43:30 -0500 > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > sde@recombinant.demon.co.uk > Sent: Wednesday, March 22, 2000 4:13 PM > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] float("1.0e-309") inconsistency on win32 > (PR#245) > > > Full_Name: Stephen D Evans > Version: 1.5.2 > OS: win32 > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > #! /usr/bin/python > > # Inconsistent behaviour. > > # Python 1.5.2 win32 fails the second print (why not both?) > # other versions print both expressions > > # Ok Python 1.5.2 on SuSE Linux 6.3 > # Ok JPython 1.1 on java1.1.7B > # Partial failure Python 1.5.2 win32 > > print eval("float(1.0e-309)") > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 First note that these don't do the same thing: the first passes a float to "float", the second passes a string to "float". Change the first to print eval("float('1.0e-309')") and it gives the same bogus error as the second one. Then it turns out the error is Microsoft's fault. This tiny C program shows the bug: #include #include #include void main() { double x; char* dontcare; errno = 0; x = strtod("1.0e-309", &dontcare); printf("errno after = %d\n", errno); printf("x after = %g\n", x); } This prints errno after = 34 x after = 0 when compiled & linked with MS's VC5; don't know about VC6. Same thing for "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS fixes their library. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 04:51:57 -0500 > > Full_Name: Stephen D Evans > > Version: 1.5.2 > > OS: win32 > > Submission from: recombinant.demon.co.uk (212.229.73.7) > > > > > > #! /usr/bin/python > > > > # Inconsistent behaviour. > > > > # Python 1.5.2 win32 fails the second print (why not both?) > > # other versions print both expressions > > > > # Ok Python 1.5.2 on SuSE Linux 6.3 > > # Ok JPython 1.1 on java1.1.7B > > # Partial failure Python 1.5.2 win32 > > > > print eval("float(1.0e-309)") > > print float("1.0e-309") # ValueError: float() literal too large: 1.0e-309 > > First note that these don't do the same thing: the first passes a float to > "float", the second passes a string to "float". Change the first to > > print eval("float('1.0e-309')") > > and it gives the same bogus error as the second one. > > Then it turns out the error is Microsoft's fault. This tiny C program shows > the bug: > > #include > #include > #include > > void > main() > { > double x; > char* dontcare; > errno = 0; > x = strtod("1.0e-309", &dontcare); > printf("errno after = %d\n", errno); > printf("x after = %g\n", x); > } > > This prints > > errno after = 34 > x after = 0 > > when compiled & linked with MS's VC5; don't know about VC6. Same thing for > "1.0e-308". Works fine for "1.0e-307". Doubt this will get fixed before MS > fixes their library. The bizarre thing is that this is broken the same way on Solaris: >>> 1.0e-309 1.0000000000000019e-309 >>> float("1.0e-309") Traceback (innermost last): File "", line 1, in ? ValueError: float() literal too large: 1.0e-309 >>> I looked and it turns out that Python uses atof() in the first case (string literal encountered in a Python expression) and strtod() in the second case (string passed to float()). Apparently strtod() and atof() differ in implementation, even though the Solaris man page says "The atof(str) function call is equivalent to strtod(str, (char **)NULL)." We could fix this by changing float() to do its own syntax checking and then use atof()... Is it worth it? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 22:48:50 -0500 [atof and strtod act differently given denormals on both Windows & Solaris] [Guido] > ... > Apparently strtod() and atof() differ in implementation, even though > the Solaris man page says "The atof(str) function call is equivalent > to strtod(str, (char **)NULL)." Ya, their man page is lying. atof() existed in the mists of prehistory and typically did no error checking at all. IIRC, ANSI C introduced strtod(), which generally got implemented as a layer of error-checking around atof. I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero inputs with absolute value smaller than that. > We could fix this by changing float() to do its own syntax checking > and then use atof()... Is it worth it? Depends on your goal : do you want more extreme cases, like 1e-500, to blow up (strtod) or underflow to 0 (atof)? The example in the original test case is subtler because atof made it *appear* to be "a regular old number"; in fact, it's not, it's small enough that it falls into 754's "denormalized" range. This means the conversion loses some extraordinary amount of-- but not all --information (whereas 1e-500 is below even the denorm range: conversion loses all information). Without a coherent strategy for dealing with 754 issues, it's hard to decide which is better. Since strtod() is more restrictive, if this is worth bothering about at all now (for P3K I think 754 needs to be taken seriously), I actually recommend changing current atof() calls to use native strtod() instead. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:14:29 -0500 > [atof and strtod act differently given denormals on both Windows & > Solaris] > > [Guido] > > ... > > Apparently strtod() and atof() differ in implementation, even though > > the Solaris man page says "The atof(str) function call is equivalent > > to strtod(str, (char **)NULL)." [Tim] > Ya, their man page is lying. atof() existed in the mists of prehistory and > typically did no error checking at all. IIRC, ANSI C introduced strtod(), > which generally got implemented as a layer of error-checking around atof. > > I have to take it back that this is a bug in MS's strtod: DBL_MIN is MS's > limits.h is 2.2250738585072014e-308, so strtod() *should* gripe on non-zero > inputs with absolute value smaller than that. > > > We could fix this by changing float() to do its own syntax checking > > and then use atof()... Is it worth it? > > Depends on your goal : do you want more extreme cases, like 1e-500, > to blow up (strtod) or underflow to 0 (atof)? The example in the original > test case is subtler because atof made it *appear* to be "a regular old > number"; in fact, it's not, it's small enough that it falls into 754's > "denormalized" range. This means the conversion loses some extraordinary > amount of-- but not all --information (whereas 1e-500 is below even the > denorm range: conversion loses all information). > > Without a coherent strategy for dealing with 754 issues, it's hard to decide > which is better. Since strtod() is more restrictive, if this is worth > bothering about at all now (for P3K I think 754 needs to be taken > seriously), I actually recommend changing current atof() calls to use > native strtod() instead. Hm, I'm not so sure. Suppose I'm writing a program that reads a data files generated by some Fortran program. The Fortran program is giving me points to plot for example. If Fortran manages to output 1e-500, wouldn't it make more sense if I rounded that to zero instead of rejecting it? After all, after converting to plot precision it's going to be zero anyway. This way I could almost defend using strtod() for literals in Python source code (where it makes more sense to warn about underflow) but atof() for input. Except that of course input could conceivably be using eval()... Another argument for turning underflow into zero is that that also happens in regular arithmetic: >>> 0.1**2**8 1.0000000000000275e-256 >>> 0.1**2**9 0.0 I like this uniform behavior: overflow -> exception, underflow -> zero. My calculator does this too. Am I hopelessly naive about this? What else can we do? What control does C give? What does sscanf() do? --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Fri, 24 Mar 2000 23:53:10 -0500 "In the face of ambiguity, refuse the temptation to guess". That's one of the Pythonic Theses you're tempted to ignore too often . Part of taking 754 seriously is that 754 gives the user complete control over what happens in case of exceptions (including underflow): ignore them, raise a fatal error, or simply set a flag saying it occurred. Unfortunately, we have to wait for C9x until there's a portable way to get at that stuff. Before then, it requires wildly varying platform-specific hair. > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > files generated by some Fortran program. The Fortran program is > giving me points to plot for example. If Fortran manages to output > 1e-500, wouldn't it make more sense if I rounded that to zero instead > of rejecting it? This *may* make good sense if Python had certain knowledge that the program is merely going to plot the points, but probably not even then. That is, "insignificantly small" is relative to the application, and e.g. for all we know the Fortran program generated a million doubles *all* in the range [1e-500, 10e-500]: the intended plot of the data could very well be a pointillistic version of the Mona Lisa rather than a straight line. > After all, after converting to plot precision it's > going to be zero anyway. As above, this conclusion relies on the dubious assumption that 1e-500 is very much smaller than the other values. > This way I could almost defend using strtod() for literals in > Python source code (where it makes more sense to warn about underflow) > but atof() for input. Except that of course input could conceivably > be using eval()... > > Another argument for turning underflow into zero is that that also > happens in regular arithmetic: > > >>> 0.1**2**8 > 1.0000000000000275e-256 > >>> 0.1**2**9 > 0.0 Which is often desired but sometimes a disaster -- the language simply can't guess. On whatever machine you ran this on, it almost certainly set the "underflow happened" flag but continued on because the underflow exception was masked out by default. > I like this uniform behavior: overflow -> exception, underflow -> > zero. My calculator does this too. Not mine . Really, whether underflow gripes is controlled by a user-settable flag on high end HP calculators. Note too that neither does float *overflow* raise an exception under most Pythons today: D:\Python>python Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 1e500 1.#INF >>> 1e200**2 1.#INF >>> I personally favor raising exceptions (by default) on 754's overflow, divide by 0, and invalid operation conditions, while (again by default) letting underflow and inexact pass without comment. But it again requires fiddling the HW's 754 control registers to make that happen. P3K, not now. > Am I hopelessly naive about this? Not *entirely* hopeless, but close . If we ever talk about it for an hour, I'll convince you of the futility of fighting 754. They beat all resistance out of me in a mere decade <0.5 wink>. > What else can we do? Not much! Switching uniformly to either atof() or strtod() would be OK by me for now, although I don't think patching over the current inconsistency buys enough bang for the buck to be worth the effort. > What control does C give? None, until C9X. > What does sscanf() do? I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI C's numerics fight the *right* thing to do now just about every step of the way. C9x is supposed to fix all that. In the meantime, I think what JPython does is much more interesting (but don't know what that is): whatever we do here should be consistent with The Other Python too, and Java has a much better 754 story than ANSI C. 754 is here to stay, but the last iteration of ANSI C isn't. Best guess is that Java acts more like atof than strtod in this case. ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Sat, 25 Mar 2000 14:15:54 -0500 > "In the face of ambiguity, refuse the temptation to guess". > > That's one of the Pythonic Theses you're tempted to ignore too often . > > Part of taking 754 seriously is that 754 gives the user complete control > over what happens in case of exceptions (including underflow): ignore them, > raise a fatal error, or simply set a flag saying it occurred. > Unfortunately, we have to wait for C9x until there's a portable way to get > at that stuff. Before then, it requires wildly varying platform-specific > hair. OK, so let's stick with the defaults that 754 presecribes until we can give the user control. That's the purpose of defaults, right? > > Hm, I'm not so sure. Suppose I'm writing a program that reads a data > > files generated by some Fortran program. The Fortran program is > > giving me points to plot for example. If Fortran manages to output > > 1e-500, wouldn't it make more sense if I rounded that to zero instead > > of rejecting it? > > This *may* make good sense if Python had certain knowledge that the program > is merely going to plot the points, but probably not even then. That is, > "insignificantly small" is relative to the application, and e.g. for all we > know the Fortran program generated a million doubles *all* in the range > [1e-500, 10e-500]: the intended plot of the data could very well be a > pointillistic version of the Mona Lisa rather than a straight line. OK, forget the example. > > After all, after converting to plot precision it's > > going to be zero anyway. > > As above, this conclusion relies on the dubious assumption that 1e-500 is > very much smaller than the other values. I think even 754 tells us that 1e-500 is smaller than what we normally need to deal with. > > This way I could almost defend using strtod() for literals in > > Python source code (where it makes more sense to warn about underflow) > > but atof() for input. Except that of course input could conceivably > > be using eval()... > > > > Another argument for turning underflow into zero is that that also > > happens in regular arithmetic: > > > > >>> 0.1**2**8 > > 1.0000000000000275e-256 > > >>> 0.1**2**9 > > 0.0 > > Which is often desired but sometimes a disaster -- the language simply can't > guess. On whatever machine you ran this on, it almost certainly set the > "underflow happened" flag but continued on because the underflow exception > was masked out by default. Again: 754 gives a default. I want to conform to the default -- it's better to provide control, but even when we provide control, there will still be default behavior, and (if I understand 754 correctly) the default is not to interrupt for underflow. > > I like this uniform behavior: overflow -> exception, underflow -> > > zero. My calculator does this too. > > Not mine . Really, whether underflow gripes is controlled by a > user-settable flag on high end HP calculators. Note too that neither does > float *overflow* raise an exception under most Pythons today: > > D:\Python>python > Python 1.5.42 (#0, Jan 31 2000, 14:05:14) [MSC 32 bit (Intel)] on win32 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> 1e500 > 1.#INF > >>> 1e200**2 > 1.#INF > >>> Oops, you're right. Must be another 754 default behavior! > I personally favor raising exceptions (by default) on 754's overflow, divide > by 0, and invalid operation conditions, while (again by default) letting > the HW's 754 control registers to make that happen. P3K, not now. I would personally also prefer an exception for overflow. You don't say what you want for underflow though. I still like silent underflow to zero by default. > > Am I hopelessly naive about this? > > Not *entirely* hopeless, but close . If we ever talk about it for an > hour, I'll convince you of the futility of fighting 754. They beat all > resistance out of me in a mere decade <0.5 wink>. I'm not fighting it. Say the ideal Python has full user control over fp exceptions. What should the defaults be? Python 1.6 should have the same defaults, even if it doesn't have the controls. > > What else can we do? > > Not much! Switching uniformly to either atof() or strtod() would be OK by > me for now, although I don't think patching over the current inconsistency > buys enough bang for the buck to be worth the effort. > > > What control does C give? > > None, until C9X. > > > What does sscanf() do? > > I don't care -- ANSI C predated 754's absolute universal triumph, and ANSI > C's numerics fight the *right* thing to do now just about every step of the > way. C9x is supposed to fix all that. > > In the meantime, I think what JPython does is much more interesting (but > don't know what that is): whatever we do here should be consistent with The > Other Python too, and Java has a much better 754 story than ANSI C. 754 is > here to stay, but the last iteration of ANSI C isn't. Best guess is that > Java acts more like atof than strtod in this case. Bingo. Indeed it does. 1e500 prints as Infinity; 1e-500 is 0.0, either as literal or when converted from a string. I'll change float() to use atof(). --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Jul-31 14:08 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] float("1.0e-309") inconsistency on win32 (PR#245) Date: Tue, 4 Apr 2000 00:29:01 -0400 [Guido] > OK, so let's stick with the defaults that 754 presecribes until we can > give the user control. That's the purpose of defaults, right? In every world other 754 (see below), but we really have no choice now (because C doesn't give us any control now). > I think even 754 tells us that 1e-500 is smaller than what we normally > need to deal with. Well, there is no 1e-500 under 754, which is why there's some reason to at least warn about it (if the user wanted 0, why didn't they type 0?). > Again: 754 gives a default. I want to conform to the default -- it's > better to provide control, but even when we provide control, there will > still be default behavior, and (if I understand 754 correctly) the > default is not to interrupt for underflow. The 754 default is never to raise an exception no matter what, whether overflow, underflow, invalid operation (like sqrt(-4)), or divide by 0. So Python's current behavior wrt these two is non-conforming: math.sqrt(-4) 1. / 0. However, 754 is primarily a HW std, and the defaults were prescribed by a committee of HW geeks and math library authors. They were caught totally off guard by how long it took for languages to provide the control features the std also mandates -- for "regular users" it's plainly insane to avoid griping about the two above, and it was never 754's intent to let them pass silently for regular users. Note that Java has been skewered mercilessly by Kahan (Mr. 754 Himself) for accepting the defaults but not providing the also-mandated control functions. The std is subtler than it appears, and all the fiddly bits are really needed. >> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >> >>> 1e500 >> 1.#INF >> >>> 1e200**2 >> 1.#INF >> >>> > Oops, you're right. Must be another 754 default behavior! Right. > I would personally also prefer an exception for overflow. You don't > say what you want for underflow though. I still like silent underflow > to zero by default. 754 defines (almost) everything: underflow when the underflow exception is masked out must deliver a zero with the same sign as the infinite-precision result. > I'm not fighting it. You will ; e.g., returning 1 for "x == x" is incorrect when x is a NaN. > Say the ideal Python has full user control over fp exceptions. What > should the defaults be? IMO, exception on overflow, divide-by-0 and invalid operation. Let underflow and inexact pass silently. That's what I implemented at KSR, and customers were *very* much happier with that than with the 754 defaults. Of course I also implemented all the 754 control and status inquiry functions, so the one 754-savvy programmer per site was happy too (they need the control to write robust numerical libraries for everyone else to use -- the *true* purpose of the 754 HW defaults). > Python 1.6 should have the same defaults, even if it doesn't have the > controls. This is a big project, as there's no portable way even to detect fp overflow now. The math libraries should play along too. > I'll change float() to use atof(). OK by me! ------------------------------------------------------- Date: 2000-Aug-03 05:43 By: twouters Comment: I *think* this one is fixed and closed. It looks like Guido promises to fix this, in any case, and it looks done. ------------------------------------------------------- Date: 2000-Aug-10 11:48 By: gvanrossum Comment: No, it's not fixed, but it is platform dependent how it behaves. The conclusion was that we should use atof() everywhere, and write a separate syntax checker (since atof() stops at the first invalid character). I made a start at a syntax checker but then got distracted. Here's my code: static char * floatsyntax(char *s) { /* Check for valid floating point syntax: space* [sign] (digit+ [period digit*] | period digit+) [(e|E) [sign] digit+] space* */ int digits, period; while (isspace(*s)) s++; if (*s == '+' || *s == '-') s++; digits = period = 0; for (;;) { if (isdigit(*s)) digits++; else if (*s == '.') { if (period) return NULL; period++; } else break; } if (!digits) return NULL; if (*s == 'e' || *s == 'E') { s++; if (*s == '+' || *s == '-') s++; digits = 0; while (isdigit(*s)) digits++; if (!digits) return NULL; } return s; } ------------------------------------------------------- Date: 2000-Aug-10 11:51 By: gvanrossum Comment: Shit. SF removes leading whitespace. Oh well, mail me for a properly formatted version of that code. ------------------------------------------------------- Date: 2000-Aug-10 21:57 By: tim_one Comment: It's curious that in the change mail SF generated, leading indentation was *not* lost. This must be a browser display thing. Anyway, by eyeball the syntax checker has two bugs: 1. Infinite loop when looking at an exponent. x while (isdigit(*s)) digits++; should be x while (isdigit(*s)) {digits++; s++;) 2. Like atof, stops at an invalid character. Before the x return s; it should have, e.g., x while (ispace(*s)) ++s; x if (*s) return NULL; although I'm not sure what the assumptions are about the input to this function. ------------------------------------------------------- Date: 2000-Aug-27 11:38 By: gvanrossum Comment: I'm mailing Tim a fixed version of floatsyntax(). ------------------------------------------------------- Date: 2000-Aug-30 00:39 By: tim_one Comment: I'm afraid the code here is a freakin' mess. No wonder Guido assigned it to me <0.3 wink>. Turnabout is fair play, so I'm assigning it back to him (for Pronouncements, or at least to alert him what's going on here). I *think* you intended to change the guts of PyFloat_FromString. Which appears to be a so-far undocumented public API function, with a strtod-like prototype, and where nobody calls it with anything but NULL for the 2nd argument. Does the signature of this have to remain the same, or can I toss the 2nd argument? Or even define it to do something useful ? Note that in the Unicode case, pend is set to point into stack trash! Python has its own strtod.c and atof.c files too. Are these really needed, or can I toss those as well? (They're not used on Windows, but I don't understand the layers of Unix config.) They're both ANSI std, so I don't think we should be supplying our own anymore (besides which, they suck numerically). Bad news: our strategy for fixing this bug relies on atof() behavior that's explicitly not defined by the std (if strtod sets errno on a given input, the result of atof on that same input is undefined). Let's assume from here on that we're just lucky. Note that complex_from_string (bltinmodule.c) does its own by-hand parsing, again calling strtod directly, so the bug here will just pop up there too. Ditto for load_float in cpickle.c (we can *write out* flost strings that strtod won't read back in -- in effect, that *is* this bug, in another guise). Ditto for strop_atof in stropmodule.c. If we *don't* assume we're lucky, there are about 6 calls to atof that are vulnerable too. Unfortunately, C did a bad job of defining float<->string facilities, and C's problems have propagated throughout Python (i.e., wherever atof or strtod are called). Note that atof/strtod both get much hairier in C99 (they sprout new ways to spell NaN and Inf, and support a new binary floating-point notation too). The Python code calling these guys now doesn't know anything about that, so it will again be a distributed mess to fix all the call sites. I suggest there should be exactly one routine in the entire source tree that converts strings to doubles, exactly one in the other direction too; and outside of the former, calls to atof and strtod should be strictly banned. C is a mess here, C99 is less of a mess but much more complex, and we can't afford to have the mess or the complexity spread throughout the codebase. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110624&group_id=5470 From noreply@sourceforge.net Wed Aug 30 10:21:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 02:21:44 -0700 Subject: [Python-bugs-list] [Bug #113037] auotconf/build problems on HP-UX Message-ID: <200008300921.CAA00854@delerium.i.sourceforge.net> Bug #113037, was updated on 2000-Aug-29 06:57 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: auotconf/build problems on HP-UX Details: From: Mike Romberg To: jeremy@beopen.com Subject: Fwd: [Bug #111319] Autoconfig breakdown with gnu libc-2.1.3 (noreply@sourceforge.net) Date: Mon, 28 Aug 2000 11:49:48 -0600 (MDT) >>>>> " " == Jeremy Hylton writes: > Mike, I can't reproduce the bug you report. Can you check > against the current CVS and see if it still has the problem? > It may be that the bug has been fixed since you reported it. Here is a followup. Using the CVS tree from last friday, this is what I get: 1 - Default install seems to enable threads and cycle-gc. This has core dumps. 2 - --without-thread. Dumps core as well. 3 - --without-cycle-gc --without-thread. This has some kind of problem with the importer. It breaks with 'from foo import *'. 4 - I attempted to build this CVS version on HP-UX so that I might run purify with it. The CVS version did not build on HP-UX. The build fails with a 'no rule to make dynload-hpux' (or something really close). I removed this object file from the Makefile. But the build failed later on with undeclared functions. I'm still going to try using purify with python-1.6b1 (which did compile on HP-UX). So, I tried getting a new CVS version this morning. This core dumps right off the bat (compiled with --without-cycle-gc --without-thread). #0 do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:353 #1 0x869f0c0 in do_mktuple (p_format=0xbfffe710, p_va=0xbfffe714, endchar=41, n=4) at modsupport.c:223 #2 0x869f189 in do_mkvalue (p_format=0xbfffe710, p_va=0xbfffe714) at modsupport.c:247 #3 0x869f430 in Py_VaBuildValue (format=0x8a1d8a2 "(OOOO)", va=0xbfffe744) at modsupport.c:415 #4 0x869f3c6 in Py_BuildValue (format=0x8a1d8a2 "(OOOO)") at modsupport.c:390 #5 0x868f1f7 in eval_code2 (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1630 #6 0x868d3b8 in PyEval_EvalCode (co=0x8f4c1b8, globals=0x8f4c288, locals=0x8f4c288) at ceval.c:313 #7 0x869aaaf in PyImport_ExecCodeModuleEx (name=0xbfffe914 "site", co=0x8f4c1b8, pathname=0x8a203ea "") at import.c:497 #8 0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site") at import.c:1387 #9 0x869b869 in load_module (name=0xbfffeda4 "site", fp=0x0, buf=0xbfffe914 "site", type=7) at import.c:1232 #10 0x869c44c in import_submodule (mod=0x8bfe48c, subname=0xbfffeda4 "site", fullname=0xbfffeda4 "site") at import.c:1727 #11 0x869c00d in load_next (mod=0x8bfe48c, altmod=0x8bfe48c, p_name=0xbffff1b0, buf=0xbfffeda4 "site", p_buflen=0xbfffeda0) at import.c:1583 #12 0x869bc83 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at import.c:1434 #13 0x869bdbc in PyImport_ImportModuleEx (name=0x8a216c3 "site", globals=0x0, locals=0x0, fromlist=0x0) at import.c:1475 #14 0x869bc20 in PyImport_ImportModule (name=0x8a216c3 "site") at import.c:1408 #15 0x86a014b in initsite () at pythonrun.c:429 #16 0x869fdca in Py_Initialize () at pythonrun.c:166 #17 0x80dbf4c in main (argc=1, argv=0xbffff2d4) at main.C:22 Follow-Ups: Date: 2000-Aug-29 09:12 By: jhylton Comment: More details from comp.lang.python: From: Philipp Jocham Subject: Re: need help with build on HP-UX Newsgroups: comp.lang.python Date: Tue, 29 Aug 2000 11:23:25 GMT Message-ID: Python-1.6b1 on HP-UX 11.00 build with gcc-2.8.1 % ./configure --with-threads [...] checking for --with-thread... yes checking for mach/cthreads.h... no checking for pth_init in -lpth... no checking for pthread_create in -lpthread... no checking for pthread_detach... no checking for kernel/OS.h... no checking for pthread_create in -lpthreads... no checking for pthread_create in -lc_r... no checking for __d6_pthread_create in -lthread... no checking for pthread_create in -lcma... yes [...] % make % make test yields [...] PYTHONPATH= ./python -tt ./Lib/test/regrtest.py pthread_mutex_init: Invalid argument sh: 5019 Memory fault(coredump) *** Error exit code 139 (ignored) I've experienced a similar problem with python-1.5.2 see http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=110665 The problem is the same. The function pthread_create is a macro in sys/pthread.h and pointing to __pthread_create_system. Finally pthread_create is detected in /usr/lib/libcma.a, which doesn't have a compatible pthread_mutex_init function. Hacking the Makefiles (after running configure) by changing the LIBS= lines from LIBS= -lnet -lnsl -ldld -lcma to LIBS= -lnet -lnsl -ldld -lpthread -lcl links the object-files against the pthread library. This solution has worked for 1.5.2 and runs at least all tests correctly for 1.6b1 A solution might be to add a test for __pthread_create_system in /usr/lib/libpthread.a in the configure.in script. ------------------------------------------------------- Date: 2000-Aug-29 09:15 By: jhylton Comment: Another suggestion from comp.lang.python From: Michael Maul Subject: Re: need help with build on HP-UX Newsgroups: comp.lang.python Date: Tue, 29 Aug 2000 10:33:05 -0400 Message-ID: <39ABC9A0.C584B210@nortelnetworks.com> Goto link below for instructions and patches for building python 152 with threads on hpux 10.20 with DCE threads http://memaul.tripod.com/index.html ------------------------------------------------------- Date: 2000-Aug-30 02:21 By: lemburg Comment: > #8 0x869bb82 in PyImport_ImportFrozenModule (name=0xbfffe914 "site") > at import.c:1387 Why does Python try to import site as frozen module ? Could it be that you have frozen site.py using a pre-2.0 Python version and that this causes the core dump ? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113037&group_id=5470 From noreply@sourceforge.net Wed Aug 30 12:57:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 04:57:12 -0700 Subject: [Python-bugs-list] [Bug #113106] distutils' msvccompiler.py has small C++ defects Message-ID: <200008301157.EAA12285@bush.i.sourceforge.net> Bug #113106, was updated on 2000-Aug-30 04:57 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: distutils' msvccompiler.py has small C++ defects Details: At least in 1.6b1, the msvccompiler.py module of distutils has a couple of lacks in C++ support, that show up strongly at least when building the "CXX" extension (I also submitted those to the CXX group, but there's little they can do about them, I think). a) .cxx is not a recognized extension -- it should be listed together with .cc and .cpp, as it's quite common (and it's the one used by the CXX group, as it happens). Falling-off-a-log-easy to fix. b) the /GX switch is not given when building C++ sources, which causes (at the very least) warnings from the standard C++ library headers, erroneous handling of exceptions, etc. Pretty easy to fix as each sourcefile is being separately identified as C++ or C source, just no use is being made of this yet to select the compilation options (I think /gx should be mandatory for C++ sources to give behavior closer to C++ standard, make C++ standard library usable, etc; /gr for RTTI is a harder decision as it imposes some overhead). Alex For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113106&group_id=5470 From noreply@sourceforge.net Wed Aug 30 13:39:30 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 05:39:30 -0700 Subject: [Python-bugs-list] [Bug #110625] trouble building under Solaris 7 (PR#260) Message-ID: <200008301239.FAA07741@delerium.i.sourceforge.net> Bug #110625, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: trouble building under Solaris 7 (PR#260) Details: Jitterbug-Id: 260 Submitted-By: lipman@helix.nih.gov Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST) Version: 1.5.2 OS: Solaris 7 106541-08 When I built Python on my machine: SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10 Python's internal symbols (for instance PySequence_Length) were not included in the dynamic symbol table of the python executable. This prevented the Numerical-15.2 extensions from importing properly. My machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker installed. I use the GNU linker, which is first in the $PATH under which Python was built. A workaround for this problem is to change the following line in Modules/Makefile.pre from LDFLAGS= to LDFLAGS= -export-dynamic This will only work for the GNU linker. ==================================================================== Audit trail: Mon May 22 17:39:59 2000 guido changed notes Mon May 22 17:39:59 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-06 14:25 By: twouters Comment: This might be fixed by newer autoconf ? ------------------------------------------------------- Date: 2000-Aug-30 05:39 By: akuchling Comment: Reassigning to Jeremy, since I lack the time. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110625&group_id=5470 From noreply@sourceforge.net Wed Aug 30 18:13:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 10:13:38 -0700 Subject: [Python-bugs-list] [Bug #110861] time.sleep() and threading (PR#307) Message-ID: <200008301713.KAA18183@delerium.i.sourceforge.net> Bug #110861, was updated on 2000-Aug-01 14:39 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: Works For Me Bug Group: Irreproducible Priority: 5 Summary: time.sleep() and threading (PR#307) Details: Jitterbug-Id: 307 Submitted-By: gpk@bell-labs.com Date: Fri, 28 Apr 2000 11:28:19 -0400 (EDT) Version: 1.5.2 OS: Solaris 2.6 sparc python .../test/test_thread.py shows that time.sleep() does not relinquish the processor. As one thread goes to sleep, another thread ought to start processing. That doesn't happen. Python was configured with --with-thread and compiler flags -mt and -D_REENTRANT. See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g EXAMPLE: hce* python test_thread.py creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 9.9 sec # goes to sleep here... task 1 done # 9.9 seconds later... task 5 will run for 4.1 sec # This should have started when task 1 slept. task 5 done task 7 will run for 9.9 sec task 7 done task 4 will run for 9.2 sec task 4 done task task 6 will run for 7.7 sec ==================================================================== Audit trail: Mon May 22 17:23:26 2000 guido changed notes Mon May 22 17:23:26 2000 guido moved from incoming to irreproducible Follow-Ups: Date: 2000-Aug-01 14:39 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] time.sleep() and threading (PR#307) Date: Wed, 03 May 2000 11:58:20 -0400 > python .../test/test_thread.py shows that time.sleep() > does not relinquish the processor. > As one thread goes to sleep, another thread ought > to start processing. That doesn't happen. > > Python was configured with --with-thread > and compiler flags -mt and -D_REENTRANT. > See line from config.status: s%@CC@%cc -mt -D_REENTRANT%g > > EXAMPLE: > > hce* python test_thread.py > creating task 1 > creating task 2 > creating task 3 > creating task 4 > creating task 5 > creating task 6 > creating task 7 > creating task 8 > creating task 9 > creating task 10 > waiting for all tasks to complete > task 1 will run for 9.9 sec # goes to sleep here... > task 1 done # 9.9 seconds later... > task 5 will run for 4.1 sec # This should have started when task 1 slept. > task 5 done > task 7 will run for 9.9 sec > task 7 done > task 4 will run for 9.2 sec > task 4 done > task task 6 will run for 7.7 sec Hm... It works correctly for me on Solaris 7 compiled with gcc, using either Solaris threads or Posix threads. I wonder if this could have something to do with the compiler you are using? (Are you using the SunPro compiler?) There's not much I can do about this right now, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:39 By: none Comment: And wqent away when he upgraded to Py 1.6. ------------------------------------------------------- Date: 2000-Aug-25 10:47 By: jhylton Comment: Can you test this with Sun's compiler? ------------------------------------------------------- Date: 2000-Aug-30 10:13 By: gward Comment: I built the latest CVS Python 2.0 source on Solaris 2.6 with both GCC and the Sun Workshop compiler (4.2). The test seems to be correct, ie. I don't get any long delays while task 1 is sleeping before subsequent tasks start up. Haven't tried any earlier Python release. Does anyone care, or should we call this one "Fixed in 2.0"? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110861&group_id=5470 From noreply@sourceforge.net Wed Aug 30 18:34:47 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 10:34:47 -0700 Subject: [Python-bugs-list] [Bug #113106] distutils' msvccompiler.py has small C++ defects Message-ID: <200008301734.KAA18925@delerium.i.sourceforge.net> Bug #113106, was updated on 2000-Aug-30 04:57 Here is a current snapshot of the bug. Project: Python Category: Distutils Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: distutils' msvccompiler.py has small C++ defects Details: At least in 1.6b1, the msvccompiler.py module of distutils has a couple of lacks in C++ support, that show up strongly at least when building the "CXX" extension (I also submitted those to the CXX group, but there's little they can do about them, I think). a) .cxx is not a recognized extension -- it should be listed together with .cc and .cpp, as it's quite common (and it's the one used by the CXX group, as it happens). Falling-off-a-log-easy to fix. b) the /GX switch is not given when building C++ sources, which causes (at the very least) warnings from the standard C++ library headers, erroneous handling of exceptions, etc. Pretty easy to fix as each sourcefile is being separately identified as C++ or C source, just no use is being made of this yet to select the compilation options (I think /gx should be mandatory for C++ sources to give behavior closer to C++ standard, make C++ standard library usable, etc; /gr for RTTI is a harder decision as it imposes some overhead). Alex Follow-Ups: Date: 2000-Aug-30 10:34 By: gward Comment: OK, the .cxx extension was easy to add -- done and checked in. I'm not sure how to deal with /GX, though: is it OK to include this option when compiling C code? If so, it's a snap: just add it to the 'compile_options' attribute. If not, it's a wee bit trickier. Can you try compiling a C extension with /GX and see what happens? Here's what Microsoft's online docs say: """ /GX (Enable Exception Handling) This option enables synchronous exception handling with the assumption that extern C functions never throw an exception. It is now equivalent to /EHsc. For more information, see Exception Handling Topics (C++). """ That's at: http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_.2f.gx.htm ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113106&group_id=5470 From noreply@sourceforge.net Wed Aug 30 18:46:13 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 10:46:13 -0700 Subject: [Python-bugs-list] [Bug #111403] 1.6b1 dumps core dereferencing a NULL tstate Message-ID: <200008301746.KAA24939@bush.i.sourceforge.net> Bug #111403, was updated on 2000-Aug-08 11:26 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: 1.6b1 dumps core dereferencing a NULL tstate Details: This is from an embeded python. I've not yet been able to reproduce this with a small example. But perhaps this stacktrace will be of some help. The problem seems to be that eval_code2() calls PyThreadState_GET() and gets a NULL pointer back. This pointer is dereferenced in PyFrame_New() later on which causes the core dump. The documentation seems to say that PyThreadState_GET() should never return NULL. So, there must be a bug in there somewhere. Here is the stack trace: #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 120 PyFrameObject *back = tstate->frame; (gdb) bt #0 0x86858c8 in PyFrame_New (tstate=0x0, code=0x90fff70, globals=0x9284378, locals=0x0) at frameobject.c:120 #1 0x866b022 in eval_code2 (co=0x90fff70, globals=0x9284378, locals=0x0, args=0x8eb362c, argcount=5, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x925d2e8) at ceval.c:397 #2 0x866e4ee in call_function (func=0x911aca0, arg=0x95ea3b0, kw=0x0) at ceval.c:2521 #3 0x866e09d in PyEval_CallObjectWithKeywords (func=0x95f7a60, arg=0x95ea3b0, kw=0x0) at ceval.c:2359 #4 0x863f6cf in PyObject_CallObject (o=0x95f7a60, a=0x95ea3b0) at abstract.c:1370 #5 0x83e56ed in DrawingArea::process (this=0x95f5f48, event=@0xbfffeb80) at DrawingArea.C:971 #6 0x83e5b3d in DrawingArea::dspCB (this=0x95e0b68) at DrawingArea.C:1027 #7 0x832050f in TkFDWatcher::callback (data=0x95e2048) at TkFDWatcher.C:169 #8 0x8752612 in FileHandlerEventProc (evPtr=0x935a4d8, flags=-1) at ./tclUnixNotfy.c:405 #9 0x8741d10 in Tcl_ServiceEvent (flags=-1) at ./../generic/tclNotify.c:444 #10 0x8741fae in Tcl_DoOneEvent (flags=2) at ./../generic/tclNotify.c:747 #11 0x86a8757 in Tkapp_MainLoop (self=0x8f6a178, args=0x8eb6af0) at ./_tkinter.c:1794 #12 0x866e19e in call_builtin (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2396 #13 0x866e0ab in PyEval_CallObjectWithKeywords (func=0x8f7b7f0, arg=0x8eb6af0, kw=0x0) at ceval.c:2361 #14 0x866d0cb in eval_code2 (co=0x8fb2d18, globals=0x903b9f8, locals=0x0, args=0x8f277b4, argcount=0, kws=0x8f277b4, kwcount=0, defs=0x90447c4, defcount=1, owner=0x0) at ceval.c:1680 #15 0x866cdda in eval_code2 (co=0x8f28b10, globals=0x8f294d0, locals=0x0, args=0x8f27600, argcount=1, kws=0x8f27604, kwcount=0, defs=0x0, defcount=0, owner=0x92c6238) at ceval.c:1579 #16 0x866cdda in eval_code2 (co=0x8f5b300, globals=0x8f294d0, locals=0x0, args=0x8eb8600, argcount=0, kws=0x8eb8600, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #17 0x866cdda in eval_code2 (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1579 #18 0x866afc8 in PyEval_EvalCode (co=0x8f27ae0, globals=0x8eb0038, locals=0x8eb0038) at ceval.c:290 #19 0x867d7c7 in run_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:885 #20 0x867d777 in run_err_node (n=0x8f1d0e0, filename=0x89fcacf "", globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:870 #21 0x867d719 in PyRun_String (str=0x8f1ca68 "import GFE; GFE.main()\n", start=257, globals=0x8eb0038, locals=0x8eb0038) at pythonrun.c:847 #22 0x867ce4e in PyRun_SimpleString ( command=0x8f1ca68 "import GFE; GFE.main()\n") at pythonrun.c:589 #23 0x8681c51 in Py_Main (argc=4, argv=0xbffff204) at main.c:248 #24 0x80d90e1 in main (argc=4, argv=0xbffff204) at main.C:30 Mike Romberg (romberg@fsl.noaa.gov) Follow-Ups: Date: 2000-Aug-10 10:23 By: none Comment: Followup: This only happens when python is built --with-threads. There appears to be no problem when threads are not enabled. It should be noted that our embeded application uses no threads of any kind (python or pthreads from C++). But it may be the case that our code (C++) is not doing the right thing. It should be noted that our application works fine with python-1.5.2 compiled --with-threads. ------------------------------------------------------- Date: 2000-Aug-25 07:37 By: jhylton Comment: Mike -- Can you provide any more information about this bug? ------------------------------------------------------- Date: 2000-Aug-25 09:59 By: romberg Comment: My guess (and this is just a guess) is that this may have something to do with the interaction of python threads and Tkinter. Since most of our embeded (and non threaded) python application works fine except for one specific area, maybe that is thre problem with python 1.6. Let me attempt to explain what is going on since it may take some work to produce a small test case to reproduce the problem. Our application uses Tkinter for most of the UI. We do open a second connection to the X server using Xlib. This connection is used to render complex images into windows. Tkinter's canvas is just not fast enough. I am getting X events from these Xlib created windows via the Tcl/Tk FileEventHandler (as seen on the stack trace). I am using the Tcl/Tk C API to register for these events. The case which seems to cause the crash in python comes when I get a ButtonDown event on my second (non Tkinter) Display. This event is delivered from Tcl/Tk to some of our C++ code. Now for the interesting bit which I suspect might cause the problem. Our C++ code then releases the grab and calls into the python interpreter for it to post a popup menu (using Tkinter). This is seen on the stack as the most recent PyObject_CallObject(). This code attempts to post the Tkinter popuip menu but dies trying. This works fine under python-1.5.2 when it is built --with-thread and without. It works fine with python-1.6b2 as long as python is built without threads. But when it is built with threads I get this crash. Is it possible that the Tkinter layer is doing something different threadwise when python is built --with-threads? ------------------------------------------------------- Date: 2000-Aug-28 11:28 By: none Comment: Another followup. I've compiled python-1.6b1 on HP-UX-10.20 and linked the whole thing with purify. Purify does not show any errors and everything runs fine when python is built --without-thread. I was unable to get python to build on HP-UX --with-thread. I suspect that this might have something to do with the DCE threads HPUX uses. But in any case. The extra code linked into our embeded interpreter, is not doing anything funny with pointers (as far as purify could find). Mike (romberg@fsl.noaa.gov) ------------------------------------------------------- Date: 2000-Aug-30 10:46 By: gvanrossum Comment: Looks like just another example of HP-UX build problems. (esp. w. threads?) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111403&group_id=5470 From noreply@sourceforge.net Wed Aug 30 18:50:44 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 10:50:44 -0700 Subject: [Python-bugs-list] [Bug #111486] sys.argv in 1.6b1 Message-ID: <200008301750.KAA25117@bush.i.sourceforge.net> Bug #111486, was updated on 2000-Aug-09 07:32 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: sys.argv in 1.6b1 Details: version: 1.6b1 os: Win2k script > import sys > > for a in sys.argv: > print a called with > C:\Temp\site\bin>test 1 2 3 gives following result > C:\Temp\site\bin\test.py the parameters "1 2 3" are lost. Follow-Ups: Date: 2000-Aug-14 10:37 By: none Comment: i tried the same version with Windows ME, but couldn't reproduce the problem. but deinstalling 1.6b1 and reinstalling on Win2k didn't help. before installing 1.6b1, i had 1.5.2 running without any problems. i deinstalled 1.5.2 prior installation of 1.6b1. ------------------------------------------------------- Date: 2000-Aug-30 10:50 By: gvanrossum Comment: Assigned to Fred to verify this on Win 2000 with Python 1.6 and 2.0b1. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111486&group_id=5470 From noreply@sourceforge.net Wed Aug 30 18:54:29 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 10:54:29 -0700 Subject: [Python-bugs-list] [Bug #112628] many extensions (wrongly?) use Py_FatalError Message-ID: <200008301754.KAA25184@bush.i.sourceforge.net> Bug #112628, was updated on 2000-Aug-24 04:50 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 7 Summary: many extensions (wrongly?) use Py_FatalError Details: Many of the modules in the current CVS tree are handling errors in a manner which I find unpythonic. A typical example is pyexpat.c which at the end of initpyexpat does /* Check for errors */ if (PyErr_Occurred()) Py_FatalError("can't initialize module pyexpat"); the xml-sig group might regard this as a tragedy, but I might wish to continue and use another parser. The correct behaviour for this sort of error ought IMHO to be to raise an ImportError clean up any privately allocated resources and return. c sources which raise fatal errors _cursesmodule.c: _localemodule.c: _tkinter.c: almodule.c: cdmodule.c: errnomodule.c: fcntlmodule.c: fpectlmodule.c: linuxaudiodev.c: main.c: mathmodule.c: mpzmodule.c: parsermodule.c: pcremodule.c: posixmodule.c: puremodule.c: pyexpat.c: shamodule.c: stropmodule.c: syslogmodule.c: timemodule.c: timingmodule.c: Follow-Ups: Date: 2000-Aug-24 05:54 By: gvanrossum Comment: He's right! The proper solution is if (PyErr_Occurred()) return; since the module initialization code explicitly checks for errors raised by the module's init function. Assigned to Jeremy for pronouncement or delegation. ------------------------------------------------------- Date: 2000-Aug-24 07:54 By: bwarsaw Comment: In that case, the PyErr_Occurred() call is /usually/ not necessary, since it's done as the last thing in the init() function and would just return anyway. So given Guido's pronouncement, most of those checks can just be removed. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112628&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:01:41 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:01:41 -0700 Subject: [Python-bugs-list] [Bug #110683] can't compile with SSL support on WinNT (PR#403) Message-ID: <200008301901.MAA22191@delerium.i.sourceforge.net> Bug #110683, was updated on 2000-Jul-31 14:14 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: None Priority: 6 Summary: can't compile with SSL support on WinNT (PR#403) Details: Jitterbug-Id: 403 Submitted-By: falk.lehmann@gmx.net Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT) Version: 1.6a2 OS: WinNT 4.0 I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. The compiler stops with some warnings and an error message: K:\Projects\Python-1.6a2\Modules\socketmodule.c(2081) : error C2099: initializer is not a constant K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1947) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4047: 'function' : 'int ' differs in levels of indirection from 'void *' K:\Projects\Python-1.6a2\Modules\socketmodule.c(1948) : warning C4024: 'memset' : different types for formal and actual parameter 2 K:\Projects\Python-1.6a2\Modules\socketmodule.c(1933) : warning C4101: 'str' : unreferenced local variable K:\Projects\Python-1.6a2\Modules\socketmodule.c(2083) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'char [4]' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2084) : warning C4047: 'initializing' : 'char *' differs in levels of indirection from 'unsigned int ' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2087) : warning C4047: 'initializing' : 'int ' differs in levels of indirection from 'void (__cdecl *)(struct _object *)' K:\Projects\Python-1.6a2\Modules\socketmodule.c(2089) : warning C4047: 'initializing' : 'int (__cdecl *)(struct _object *,struct _iobuf *,int )' differs in levels of indirection from 'struct _object *(__cdecl *)(struct _object *,char *)' Thanks in advance for fixing (at least the error). Falk ==================================================================== Audit trail: Tue Jul 25 07:25:55 2000 guido changed notes Tue Jul 25 07:25:55 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-01 14:01 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 11:35:24 -0500 > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. Please try the current CVS tree (on its way to 2.0); we have no problems compiling this on VC 6.0. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: From: Falk Lehmann Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 13:46:45 -0500 [magical fwd by GvR] Guido, sorry, but forgot to write, that I switched on the USE_SSL macro. And then the _socket module does not compile. Falk > > I tried to compile Python 1.6a2 on a WinNT box using VC++ 6.00. > > Please try the current CVS tree (on its way to 2.0); we have no > problems compiling this on VC 6.0. > > --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) > ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403) Date: Mon, 24 Jul 2000 14:00:20 -0500 > sorry, but forgot to write, that I switched on the USE_SSL macro. > And then the _socket module does not compile. It appears that the Python SSL code hasn't been ported to Windows. We'll add this to our TODO list, but it's low priority... Perhaps you could give it a shot yourself? See www.python.org/patches/ for how to contribute. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/) ------------------------------------------------------- Date: 2000-Aug-01 14:02 By: none Comment: Windows compile fails when using openSSL. ------------------------------------------------------- Date: 2000-Aug-23 10:35 By: jhylton Comment: This is a bug. Standard extensions modules should compile, even on obscure platforms like Windows NT. Need a Windows user with time to install OpenSSL to fix this. ------------------------------------------------------- Date: 2000-Aug-30 12:01 By: gvanrossum Comment: Let's not worry about this for 2.0. While the OpenSSL support is part of the socket module, we don't have the resources right now to port that support to Windows. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110683&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:03:24 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:03:24 -0700 Subject: [Python-bugs-list] [Bug #113142] configure problems with poll.h Message-ID: <200008301903.MAA27837@bush.i.sourceforge.net> Bug #113142, was updated on 2000-Aug-30 12:03 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: configure problems with poll.h Details: The configure script sets HAVE_POLL to 1 but in selectmodule.c, HAVE_POLL_H is tested. And one more problem with this: When I add the "_H" to config.h, it doesn't work yet: the poll.h header file resides in /usr/include/sys. Changing `#include ' to `#include ' works for me; adding this directory via a -I flag to the selectmodule line in Modules/Setup doesn't work because it drives gcc into an endless macro recursion ... (I'm using Linux on Intel, sources fresh from the CVS tree.) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113142&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:07:10 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:07:10 -0700 Subject: [Python-bugs-list] [Bug #112265] Impossible to get Win32 default font encoding in Tk widgets Message-ID: <200008301907.MAA22405@delerium.i.sourceforge.net> Bug #112265, was updated on 2000-Aug-18 13:37 Here is a current snapshot of the bug. Project: Python Category: Tkinter Status: Open Resolution: Later Bug Group: Platform-specific Priority: 6 Summary: Impossible to get Win32 default font encoding in Tk widgets Details: I did not managed to obtain correct font encoding in widgets on Win32 (NT Workstation, Polish version, default encoding cp1250). All cp1250 Polish characters were displayed incorrectly. I think, all characters that do not belong to Latin-1 will be displayed incorrectly. Regarding Python1.6b1, I checked the Tcl/Tk installation (8.3.2). The pure Tcl/Tk programs DO display characters in cp1250 correctly. As far as I know, the Tcl interpreter woks with UTF-8 encoded strings. Does Python1.6b1 really know about it? Follow-Ups: Date: 2000-Aug-26 08:04 By: effbot Comment: this is really a "how do I", rather than a bug report ;-) ::: In 1.6 and beyond, Python's default 8-bit encoding is plain ASCII. this encoding is only used when you're using 8-bit strings in "unicode contexts" -- for example, if you compare an 8-bit string to a unicode string, or pass it to a subsystem designed to use unicode strings. If you pass an 8-bit string containing characters outside the ASCII range to a function expecting a unicode string, the result is undefined (it's usually results in an exception, but some subsystems may have other ideas). Finally, Tkinter now supports Unicode. In fact, it assumes that all strings passed to it are Unicode. When using 8-bit strings, it's only safe to use plain ASCII. Tkinter currently doesn't raise exceptions for 8-bit strings with non-ASCII characters, but it probably should. Otherwise, Tk will attempt to parse the string as an UTF-8 string, and if that fails, it assumes ISO-8859-1. ::: Anyway, to write portable code using characters outside the ASCII character set, you should use unicode strings. in your case, you can use: s = unicode("", "cp1250") to get the platform's default encoding, you can do: import locale language, encoding = locale.getdefaultlocale() where encoding should be cp1250 on your box. ::: The reason this work under Tcl/Tk is that Tcl assumes that your source code uses the platform's default encoding, and converts things to Unicode (not necessarily UTF-8) for you under the hood. Python 2.1 will hopefully support *explicit* source encodings, but 1.6/2.0 doesn't. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112265&group_id=5470 From noreply@sourceforge.net Wed Aug 30 20:51:39 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 12:51:39 -0700 Subject: [Python-bugs-list] [Bug #113145] config.h defines socklen_t, kills wxPython build Message-ID: <200008301951.MAA29599@bush.i.sourceforge.net> Bug #113145, was updated on 2000-Aug-30 12:51 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: None Priority: 5 Summary: config.h defines socklen_t, kills wxPython build Details: Building wxPython fails with 1.6 because config.h defines socklen_t; according to a comment, it checks sys/types.h. But /usr/include/bits/socket.h on Linux at least, tries to make a typedef with this name. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113145&group_id=5470 From aleaxit@yahoo.com Wed Aug 30 22:05:41 2000 From: aleaxit@yahoo.com (Alex Martelli) Date: Wed, 30 Aug 2000 23:05:41 +0200 Subject: [Python-bugs-list] Re: [Bug #113106] distutils' msvccompiler.py has small C++ defects References: <200008301734.KAA18925@delerium.i.sourceforge.net> Message-ID: <002601c012c6$3a575380$3ec02dd5@martelli> Hi, from a brief experiment, the /GX switch seems to be OK with C sources too (probably no effect?). For prudence, however, my approach had been to add it only when compiling C++ sources -- that's easy too given the way the loop is set up now (there's already an if/else to set the /Tp or /TP switch for the sourcecode; I just added another variable, to be concatenated at the end, set to either [] or ['/GX']). That's probably more prudence than actually needed here, I guess. Alex _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From noreply@sourceforge.net Thu Aug 31 00:01:40 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 16:01:40 -0700 Subject: [Python-bugs-list] [Bug #113142] configure problems with poll.h Message-ID: <200008302301.QAA04258@bush.i.sourceforge.net> Bug #113142, was updated on 2000-Aug-30 12:03 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: None Bug Group: Platform-specific Priority: 5 Summary: configure problems with poll.h Details: The configure script sets HAVE_POLL to 1 but in selectmodule.c, HAVE_POLL_H is tested. And one more problem with this: When I add the "_H" to config.h, it doesn't work yet: the poll.h header file resides in /usr/include/sys. Changing `#include ' to `#include ' works for me; adding this directory via a -I flag to the selectmodule line in Modules/Setup doesn't work because it drives gcc into an endless macro recursion ... (I'm using Linux on Intel, sources fresh from the CVS tree.) Follow-Ups: Date: 2000-Aug-30 12:41 By: lannert Comment: More recent Linux systems do have a header file, so you may forget about the second problem. Sorry. And this has probably been the reason why I didn't have HAVE_POLL_H set -- because ./configure didn't find it. Arrrgh. I'd close this bug report if I could, but I can't. (One question remains: Is it sensible to set HAVE_POLL [and die during compilation] when the header file isn't there? Maybe some systems don't need any header files for poll()?) ------------------------------------------------------- Date: 2000-Aug-30 16:01 By: jhylton Comment: lannert would close this bug if he/she could; so I will. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113142&group_id=5470 From gward@python.net Thu Aug 31 01:23:14 2000 From: gward@python.net (Greg Ward) Date: Wed, 30 Aug 2000 17:23:14 -0700 Subject: [Python-bugs-list] Re: [Bug #113106] distutils' msvccompiler.py has small C++ defects In-Reply-To: <002601c012c6$3a575380$3ec02dd5@martelli>; from aleaxit@yahoo.com on Wed, Aug 30, 2000 at 11:05:41PM +0200 References: <200008301734.KAA18925@delerium.i.sourceforge.net> <002601c012c6$3a575380$3ec02dd5@martelli> Message-ID: <20000830172314.B16383@python.net> On 30 August 2000, Alex Martelli said: > from a brief experiment, the /GX switch seems to be OK with > C sources too (probably no effect?). For prudence, however, > my approach had been to add it only when compiling C++ > sources -- that's easy too given the way the loop is set up > now (there's already an if/else to set the /Tp or /TP switch > for the sourcecode; I just added another variable, to be > concatenated at the end, set to either [] or ['/GX']). That's > probably more prudence than actually needed here, I guess. I'm checking in the easy-cheezy approach: use /GX when compiling anything. If it doesn't work for C code, we'll find out soon enough. Prudence, shmudence... Greg From noreply@sourceforge.net Thu Aug 31 03:05:18 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 19:05:18 -0700 Subject: [Python-bugs-list] [Bug #113091] ExtensionClass should be in the core Message-ID: <200008310205.TAA04790@delerium.i.sourceforge.net> Bug #113091, was updated on 2000-Aug-29 21:57 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: None Bug Group: Feature Request Priority: 5 Summary: ExtensionClass should be in the core Details: ExtensionClass, or something like it, should be part of the core interpreter. Such a facility would be used by builders of large sets of extensions to help manage internal type relationships. The Gtk+/Gnome extensions are already moving to ExtensionClass, and James Henstridge (the author) has indicated that he'd like to see better integration. Perhaps for 2.1? Follow-Ups: Date: 2000-Aug-30 19:05 By: jhylton Comment: Let's not keep this one in the bug database. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113091&group_id=5470 From noreply@sourceforge.net Thu Aug 31 06:44:02 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 22:44:02 -0700 Subject: [Python-bugs-list] [Bug #111486] sys.argv in 1.6b1 Message-ID: <200008310544.WAA17269@bush.i.sourceforge.net> Bug #111486, was updated on 2000-Aug-09 07:32 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: sys.argv in 1.6b1 Details: version: 1.6b1 os: Win2k script > import sys > > for a in sys.argv: > print a called with > C:\Temp\site\bin>test 1 2 3 gives following result > C:\Temp\site\bin\test.py the parameters "1 2 3" are lost. Follow-Ups: Date: 2000-Aug-14 10:37 By: none Comment: i tried the same version with Windows ME, but couldn't reproduce the problem. but deinstalling 1.6b1 and reinstalling on Win2k didn't help. before installing 1.6b1, i had 1.5.2 running without any problems. i deinstalled 1.5.2 prior installation of 1.6b1. ------------------------------------------------------- Date: 2000-Aug-30 10:50 By: gvanrossum Comment: Assigned to Fred to verify this on Win 2000 with Python 1.6 and 2.0b1. ------------------------------------------------------- Date: 2000-Aug-30 22:44 By: mhammond Comment: Sorry for the delay - I see it is no longer assigned to me, so I will not close it. I was waiting for my Win2k test machine to be rebooted. It now has, and I can confirm that I can not reproduce it, either on 98 or 2k. The sample program shown works correctly. I recommend it be closed as WFM. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111486&group_id=5470 From noreply@sourceforge.net Thu Aug 31 06:48:17 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 22:48:17 -0700 Subject: [Python-bugs-list] [Bug #111486] sys.argv in 1.6b1 Message-ID: <200008310548.WAA17416@bush.i.sourceforge.net> Bug #111486, was updated on 2000-Aug-09 07:32 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Works For Me Bug Group: Platform-specific Priority: 7 Summary: sys.argv in 1.6b1 Details: version: 1.6b1 os: Win2k script > import sys > > for a in sys.argv: > print a called with > C:\Temp\site\bin>test 1 2 3 gives following result > C:\Temp\site\bin\test.py the parameters "1 2 3" are lost. Follow-Ups: Date: 2000-Aug-14 10:37 By: none Comment: i tried the same version with Windows ME, but couldn't reproduce the problem. but deinstalling 1.6b1 and reinstalling on Win2k didn't help. before installing 1.6b1, i had 1.5.2 running without any problems. i deinstalled 1.5.2 prior installation of 1.6b1. ------------------------------------------------------- Date: 2000-Aug-30 10:50 By: gvanrossum Comment: Assigned to Fred to verify this on Win 2000 with Python 1.6 and 2.0b1. ------------------------------------------------------- Date: 2000-Aug-30 22:44 By: mhammond Comment: Sorry for the delay - I see it is no longer assigned to me, so I will not close it. I was waiting for my Win2k test machine to be rebooted. It now has, and I can confirm that I can not reproduce it, either on 98 or 2k. The sample program shown works correctly. I recommend it be closed as WFM. ------------------------------------------------------- Date: 2000-Aug-30 22:48 By: fdrake Comment: Closed on the basis of Mark's recommendation. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111486&group_id=5470 From noreply@sourceforge.net Thu Aug 31 07:08:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 23:08:50 -0700 Subject: [Python-bugs-list] [Bug #110622] pdb bug (PR#236) Message-ID: <200008310608.XAA12673@delerium.i.sourceforge.net> Bug #110622, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Library Status: Closed Resolution: Works For Me Bug Group: Irreproducible Priority: 5 Summary: pdb bug (PR#236) Details: Jitterbug-Id: 236 Submitted-By: jsolbrig@webcom.com Date: Tue, 14 Mar 2000 19:55:22 -0500 (EST) Version: 1.5.2 OS: Win32/win95 pdb (python debugger) tends to drop (ignore) breaks in multi-file debugging. I wish I had time to isolate the offending code but I don't. ==================================================================== Audit trail: Mon May 22 17:37:26 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-13 23:37 By: mhammond Comment: I've done extensive work with bdb and pdb, and never seen this. I believe we can close this as irreproducible, and I will in a few days unless someone screams or describes a reproduction scenario. ------------------------------------------------------- Date: 2000-Aug-30 23:08 By: mhammond Comment: Oops - marked as "irreproducible" and "works for me", but left open! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110622&group_id=5470 From noreply@sourceforge.net Thu Aug 31 07:19:46 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 23:19:46 -0700 Subject: [Python-bugs-list] [Bug #110843] Low FD_SETSIZE limit on NT (PR#41) Message-ID: <200008310619.XAA13142@delerium.i.sourceforge.net> Bug #110843, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Summary: Low FD_SETSIZE limit on NT (PR#41) Details: Jitterbug-Id: 41 Submitted-By: brian@digicool.com Date: Fri, 30 Jul 1999 10:10:49 -0400 (EDT) Version: 1.5.2 OS: NT It appears that win32 has a default limit of 64 descriptors that can be handed to the select() function. This is pretty low for any serious async servers, and causes them to raise lots of errors under very moderate loads. We at DC ran into this using Medusa as a basis for ZServer, which serves Zope sites. It turns out that you can actually add a define when compiling the python15.dll for windows to bump the default fd limit to a more reasonable level. The approach _I_ took was to add the define: FD_SETSIZE=1024 to the preprocessor options in the MSVC project settings for python15.dll, though I imagine you could also roll the define into config.h or something (so long as it's defined before windows.h or any of the select / socket include files are referenced). It would make life much easier for win32 server developers if this define could find its way into the next official python release :^) Thanks! Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com ==================================================================== Audit trail: Fri Jul 30 10:43:41 1999 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-30 23:19 By: mhammond Comment: I am a little worried that adding it to config.h may have side-effects when Python is embedded in other projects with their own socket config (eg, Mozilla :-) Now that socket and select are external .pyd modules, will it be sufficient to only add it to these extension modules? ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110843&group_id=5470 From noreply@sourceforge.net Thu Aug 31 07:23:11 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 23:23:11 -0700 Subject: [Python-bugs-list] [Bug #110637] ihooks on windows and pythoncom (PR#294) Message-ID: <200008310623.XAA13190@delerium.i.sourceforge.net> Bug #110637, was updated on 2000-Jul-31 14:09 Here is a current snapshot of the bug. Project: Python Category: Windows Status: Open Resolution: Later Bug Group: Platform-specific Priority: 3 Summary: ihooks on windows and pythoncom (PR#294) Details: Jitterbug-Id: 294 Submitted-By: mak@mikroplan.com.pl Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT) Version: cvs OS: windows Hi, Python module ihooks is not so compatible with builtin imp while importing modules whose name is stored in registry eg. pythoncom/pywintypes. import ihooks ihooks.install() import pythoncom This code will fail inside pythonwin ide too ! ==================================================================== Audit trail: Tue Jul 11 08:29:17 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-13 23:42 By: mhammond Comment: This needs a resolution. The "registered module" code in the code also needs to support HKEY_CURRENT_USER along with the HKEY_LOCAL_MACHINE it does now. ------------------------------------------------------- Date: 2000-Aug-30 23:23 By: mhammond Comment: Leaving open, but moving down the priority and resolution lists. A patch would help bump it back up :-) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110637&group_id=5470 From noreply@sourceforge.net Thu Aug 31 07:28:38 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 30 Aug 2000 23:28:38 -0700 Subject: [Python-bugs-list] [Bug #110598] Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101) Message-ID: <200008310628.XAA13349@delerium.i.sourceforge.net> Bug #110598, was updated on 2000-Jul-31 14:05 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Open Resolution: None Bug Group: None Priority: 5 Summary: Fwd: Debian Bug#46993: py_compile.compile() won't compile files with CR+LF line endings (PR#101) Details: Jitterbug-Id: 101 Submitted-By: flight@mathi.uni-heidelberg.de Date: Mon, 11 Oct 1999 15:10:37 +0200 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 ==================================================================== Audit trail: Mon Oct 11 18:12:13 1999 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-30 23:28 By: mhammond Comment: Sorry, but I dont feel able to resolve this in time for 2.0 beta or final, so giving back to Jeremy to punt back off. If post 2.0 is OK, give it on back! ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110598&group_id=5470 From noreply@sourceforge.net Thu Aug 31 08:55:04 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 00:55:04 -0700 Subject: [Python-bugs-list] [Bug #111961] urllib.quote and string.letters Message-ID: <200008310755.AAA16204@delerium.i.sourceforge.net> Bug #111961, was updated on 2000-Aug-15 07:31 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Open Resolution: None Bug Group: None Priority: 5 Summary: urllib.quote and string.letters Details: urllib.quote() uses string.letters for determining, if a character is save to be used in an url. In Python 1.5.2. this was only 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'. This seems to have changed in Python1.6b1 (or maybe it is the responsibility of the locale module) to 'abcdefghijklmnopqrstuvwxyz\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\ 370\371\372\373\374\375\376\377ABCDEFGHIJKLMNOPQRSTUVWXYZ\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\32 0\321\322\323\324\325\326\330\331\332\333\334\335\336' which changes the semantics of urllib.quote() Follow-Ups: Date: 2000-Aug-31 00:55 By: fdrake Comment: Moshe provided patch 101369 to fix this, and asked that the patch and bug be assigned to Jeremy. (Moshe's net connection is flaky at the moment.) ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111961&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:14:35 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:14:35 -0700 Subject: [Python-bugs-list] [Bug #110915] compiler core-dumps on illegal continue Message-ID: <200008311514.IAA04674@bush.i.sourceforge.net> Bug #110915, was updated on 2000-Aug-02 05:13 Here is a current snapshot of the bug. Project: Python Category: Parser/Compiler Status: Closed Resolution: Fixed Bug Group: Platform-specific Priority: 7 Summary: compiler core-dumps on illegal continue Details: On my RedHat 6.2 system, the latest CVS version of python still dumps core on the following script: ------------------------------------------------- def gentheta(): while 1: try: continue finally: pass def genkappa(): if whatsmounted!='crystal': mountcrystal() while 1: if not inhibitmake: projtls.moveoutofway('kappa',dirok=1) os.mkdir('kappa') os.chdir('kappa') try: announce("Testing Kappa zero-point") # Use the detalign.vic produced by the dx calibration dal=os.path.join('..','dx','detalign.vic') if os.path.exists(dal): print "NOTE: Using detalign.vic from dx calibration" filecopy(dal,'detalign.vic') if not inhibitmake: status=os.system('calkappa make') else: status=os.system('calkappa') if status!=0: beeper.on() answer=command.question(root,'Calkappa Warnings',text='Calkappa issued some warnings and/or errors.\nPlease check what they are, and tell me what to do', strings=("Ignore them","Retry calkappa","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break if os.path.exists('instruct.txt'): beeper.on() answer=command.fixedfontquestion( root,'Kappa missetting needs correction', text=open('instruct.txt').read(), strings=("I have now done this","I'm ignoring this for now","Cancel and quit")) beeper.off() if answer==2: cancel() if answer==1: break else: # No instructions means no correction required break finally: os.chdir('..') ------------------------------------------- Any simplification in the second function makes the compiler report the "SyntaxError: continue not properly in loop" in line 4. Stack trace: ------------------------------------------- no203[140]~%3% gdb =python GNU gdb 19991004 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run x.py Starting program: /usr/local/nonius/bin/python x.py Program received signal SIGSEGV, Segmentation fault. PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 153 if (PyClass_Check(type)) { (gdb) where #0 PyErr_NormalizeException (exc=0xbffff73c, val=0xbffff740, tb=0xbffff744) at errors.c:153 #1 0x8063901 in PyErr_PrintEx (set_sys_last_vars=1) at pythonrun.c:672 #2 0x80638d6 in PyErr_Print () at pythonrun.c:663 #3 0x806368b in PyRun_SimpleFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:574 #4 0x806335d in PyRun_AnyFile (fp=0x80cb948, filename=0xbffff9a1 "x.py") at pythonrun.c:458 #5 0x80513c7 in Py_Main (argc=2, argv=0xbffff824) at main.c:271 #6 0x8050f56 in main (argc=2, argv=0xbffff824) at python.c:10 (gdb) The program is running. Exit anyway? (y or n) y Follow-Ups: Date: 2000-Aug-07 23:34 By: hooft Comment: Since today (compile.c 2.119) This no longer dumps core, but gives the new "SystemError: lost syntax error" error message. ------------------------------------------------------- Date: 2000-Aug-25 13:47 By: jhylton Comment: Is this bug now fixed? The most recent comment suggests it is. If so, please let me know and I'll close this report. ------------------------------------------------------- Date: 2000-Aug-25 15:45 By: tim_one Comment: Well, while raising SystemError is friendlier than a core dump, at heart they're both ways to spell "the compiler is *really* confused" -- we shouldn't ever raise SystemError. ------------------------------------------------------- Date: 2000-Aug-25 15:55 By: tim_one Comment: Note comment from compile.c: /* This could happen if someone called PyErr_Clear() after * an error was reported above. That's not supposed to * happen, but I just plugged one case and I'm not sure * there can't be others. In that case, raise SystemError * so that at least it gets reported instead dumping core. */ PyErr_SetString(PyExc_SystemError, "lost syntax error"); So we got an internal error going here all right. Can't reproduce under Windows, though. ------------------------------------------------------- Date: 2000-Aug-29 12:09 By: jhylton Comment: Here's a stack trace showing the next PyErr_Clear call after SyntaxError is set. Looks like it could be a GC bug. #0 PyErr_Clear () at ../../Python/errors.c:225 #1 0x8098c1b in collect (young=0x80c9960, old=0x80c996c) at ../../Modules/gcmodule.c:447 #2 0x8098d1c in collect_generations () at ../../Modules/gcmodule.c:479 #3 0x8098d5f in _PyGC_Insert (op=0x811897c) at ../../Modules/gcmodule.c:498 #4 0x807ec14 in PyTuple_New (size=2) at ../../Objects/tupleobject.c:96 #5 0x8063d37 in do_mktuple (p_format=0xbffff1c8, p_va=0xbffff1cc, endchar=41, n=2) at ../../Python/modsupport.c:220 #6 0x8063e13 in do_mkvalue (p_format=0xbffff1c8, p_va=0xbffff1cc) at ../../Python/modsupport.c:247 #7 0x806404d in Py_VaBuildValue (format=0x80ab8c0 "(OO)", va=0xbffff1ec) at ../../Python/modsupport.c:415 #8 0x8063feb in Py_BuildValue (format=0x80ab8c0 "(OO)") at ../../Python/modsupport.c:390 #9 0x805905d in com_add (c=0xbffff7bc, list=0x811738c, dict=0x8116eb4, v=0x8118948) at ../../Python/compile.c:645 #10 0x805912d in com_addconst (c=0xbffff7bc, v=0x8118948) at ../../Python/compile.c:674 #11 0x805a1ca in com_argument (c=0xbffff7bc, n=0x81206b8, pkeywords=0xbffff270) at ../../Python/compile.c:1299 #12 0x805a2b9 in com_call_function (c=0xbffff7bc, n=0x811fd94) at ../../Python/compile.c:1332 #13 0x805a78a in com_apply_trailer (c=0xbffff7bc, n=0x811fd08) at ../../Python/compile.c:1515 #14 0x805a830 in com_power (c=0xbffff7bc, n=0x811fc80) at ../../Python/compile.c:1543 #15 0x805a8a7 in com_factor (c=0xbffff7bc, n=0x811fc60) at ../../Python/compile.c:1564 #16 0x805a8c1 in com_term (c=0xbffff7bc, n=0x811fc40) at ../../Python/compile.c:1574 #17 0x805a98d in com_arith_expr (c=0xbffff7bc, n=0x811fc20) at ../../Python/compile.c:1603 #18 0x805aa39 in com_shift_expr (c=0xbffff7bc, n=0x811fc00) at ../../Python/compile.c:1629 #19 0x805aae9 in com_and_expr (c=0xbffff7bc, n=0x811fbe0) at ../../Python/compile.c:1655 #20 0x805ab81 in com_xor_expr (c=0xbffff7bc, n=0x811fbc0) at ../../Python/compile.c:1677 #21 0x805ac19 in com_expr (c=0xbffff7bc, n=0x811fba0) at ../../Python/compile.c:1699 #22 0x805ade4 in com_comparison (c=0xbffff7bc, n=0x811fb80) at ../../Python/compile.c:1753 #23 0x805af31 in com_not_test (c=0xbffff7bc, n=0x811fb60) at ../../Python/compile.c:1828 #24 0x805af9e in com_and_test (c=0xbffff7bc, n=0x811fb40) at ../../Python/compile.c:1845 ------------------------------------------------------- Date: 2000-Aug-31 08:14 By: jhylton Comment: fixed in version 2.8 of gcmodule.c patch #101362 ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110915&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:24:14 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:24:14 -0700 Subject: [Python-bugs-list] [Bug #112468] sre/pre bug Message-ID: <200008311524.IAA31880@delerium.i.sourceforge.net> Bug #112468, was updated on 2000-Aug-21 22:05 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: None Priority: 7 Summary: sre/pre bug Details: Compiling the simple pattern '(' with pre raises an exception while sre compiles it sucessfully. Further, the regex object that sre.compile returns will match any string. Using Python 1.6b1 (#0, Aug 7 2000, 12:30:24) [MSC 32 bit (Intel)] on win32, >>> import sre >>> regex_ = sre.compile('(') >>> regex_.pattern '(' >>> regex_.search('abc').group(0) '' while >>> import pre >>> regex_ = pre.compile('(') Traceback (most recent call last): File "", line 1, in ? File "C:\Python16\lib\pre.py", line 243, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('missing )', 1) Follow-Ups: Date: 2000-Aug-22 05:34 By: gvanrossum Comment: According to Fredrik, this is a minor parsing bug in SRE. He'll fix it. ------------------------------------------------------- Date: 2000-Aug-25 07:42 By: jhylton Comment: Bumping priority so its gets fixed before release. ------------------------------------------------------- Date: 2000-Aug-31 08:24 By: effbot Comment: note: for some reason, the RE test harness ignores syntax errors under certain conditions. ...and it has done so all the time, so this is just one of many cases where SRE is more tolerant than PCRE. sigh :-( ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112468&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:45:12 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:45:12 -0700 Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue Message-ID: <200008311545.IAA32629@delerium.i.sourceforge.net> Bug #112289, was updated on 2000-Aug-18 19:50 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: NetBSD1.4.2 build issue Details: the recent fileobjects.c work done for large files (tmick) appears broken when compiled against NetBSD1.4.2. During the final link, you get the following output: gcc python.o ../libpython2.0.a -lutil -lm -o python fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment Follow-Ups: Date: 2000-Aug-18 19:55 By: none Comment: NOTE: I didn't include the configure output. If that would be helpful, go ahead and indicate that in this tracking system. If tmick (or whoever) would like me to contact them directly, I would happily do so. ------------------------------------------------------- Date: 2000-Aug-31 08:45 By: tmick Comment: Sent to python-dev: 1. Who reported this bug? He talked about providing more information and I would like to speak with him. I cannot find his email address. 2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell access to? Do you know if they have such a machine at SourceForge that users can get shell access to? Or failing that can someone with such a machine give me the full ./configure and make output and maybe run this command: find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64 and give me the output. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:47:45 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:47:45 -0700 Subject: [Python-bugs-list] [Bug #112289] NetBSD1.4.2 build issue Message-ID: <200008311547.IAA00325@delerium.i.sourceforge.net> Bug #112289, was updated on 2000-Aug-18 19:50 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 7 Summary: NetBSD1.4.2 build issue Details: the recent fileobjects.c work done for large files (tmick) appears broken when compiled against NetBSD1.4.2. During the final link, you get the following output: gcc python.o ../libpython2.0.a -lutil -lm -o python fileobject.c:280: Undefined symbol `_TELL64' referenced from text segment Follow-Ups: Date: 2000-Aug-18 19:55 By: none Comment: NOTE: I didn't include the configure output. If that would be helpful, go ahead and indicate that in this tracking system. If tmick (or whoever) would like me to contact them directly, I would happily do so. ------------------------------------------------------- Date: 2000-Aug-31 08:45 By: tmick Comment: Sent to python-dev: 1. Who reported this bug? He talked about providing more information and I would like to speak with him. I cannot find his email address. 2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell access to? Do you know if they have such a machine at SourceForge that users can get shell access to? Or failing that can someone with such a machine give me the full ./configure and make output and maybe run this command: find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64 and give me the output. ------------------------------------------------------- Date: 2000-Aug-31 08:47 By: tmick Comment: I got no reponse and I have no NetBSD machine on which to reproduce so, as Jeremy suggested, if I wouldn't get it by this evening then assign back to him. Other questions: - How old/recent is version 1.4.2 of NetBSD? - Where is _TELL64 coming from? Not from Python code. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112289&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:48:37 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:48:37 -0700 Subject: [Python-bugs-list] [Bug #111961] urllib.quote and string.letters Message-ID: <200008311548.IAA06081@bush.i.sourceforge.net> Bug #111961, was updated on 2000-Aug-15 07:31 Here is a current snapshot of the bug. Project: Python Category: Modules Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: urllib.quote and string.letters Details: urllib.quote() uses string.letters for determining, if a character is save to be used in an url. In Python 1.5.2. this was only 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'. This seems to have changed in Python1.6b1 (or maybe it is the responsibility of the locale module) to 'abcdefghijklmnopqrstuvwxyz\337\340\341\342\343\344\345\346\347\350\351\352\353\354\355\356\357\360\361\362\363\364\365\366\ 370\371\372\373\374\375\376\377ABCDEFGHIJKLMNOPQRSTUVWXYZ\300\301\302\303\304\305\306\307\310\311\312\313\314\315\316\317\32 0\321\322\323\324\325\326\330\331\332\333\334\335\336' which changes the semantics of urllib.quote() Follow-Ups: Date: 2000-Aug-31 00:55 By: fdrake Comment: Moshe provided patch 101369 to fix this, and asked that the patch and bug be assigned to Jeremy. (Moshe's net connection is flaky at the moment.) ------------------------------------------------------- Date: 2000-Aug-31 08:48 By: jhylton Comment: Fixed by patch #101369 by Moshe Zadke ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111961&group_id=5470 From noreply@sourceforge.net Thu Aug 31 16:49:56 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 08:49:56 -0700 Subject: [Python-bugs-list] [Bug #110644] bug in PyLong_FromLongLong (PR#324) Message-ID: <200008311549.IAA00370@delerium.i.sourceforge.net> Bug #110644, was updated on 2000-Jul-31 14:10 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Platform-specific Priority: 5 Summary: bug in PyLong_FromLongLong (PR#324) Details: Jitterbug-Id: 324 Submitted-By: Thomas.Malik@t-online.de Date: Wed, 10 May 2000 15:37:28 -0400 (EDT) Version: 1.5.2 OS: all there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bit integers. PyLong_FromLongLong starts with: if( ival <= (LONG_LONG)LONG_MAX ) { return PyLong_FromLong( (long)ival ); } else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { .... Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range (being a 64 bit negative integer), but gets handled by the first if-then-case in above code ('cause it is, of course, smaller than LONG_MAX). This results in truncation of the 64 bit negative integer to a more or less arbitrary 32 bit number. The way to fix it is to compare the absolute value of imax against LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at least, check wether ival is positive. ==================================================================== Audit trail: Mon May 22 17:13:25 2000 guido changed notes Mon May 22 17:13:25 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 11:20 By: tim_one Comment: Reassigned from Trent to me -- Python had the same bug in its "regular int" code for years, and I fixed it there, so I should fix it here too. 'Tis tricky to get right. ------------------------------------------------------- Date: 2000-Aug-23 15:08 By: tmick Comment: Tim, Sorry to have left this siting here. I did not know that it was assigned to me. The code is now: if ((LONG_LONG)LONG_MIN <= ival && ival <= (LONG_LONG)LONG_MAX) { return PyLong_FromLong( (long)ival ); } else if (0 <= ival && ival <= (unsigned LONG_LONG)ULONG_MAX) { return PyLong_FromUnsignedLong( (unsigned long)ival ); } else { which means that the bug is fixed n'est ce pas? I remember discussing this way back (though "way back" for me is like last week for you). ------------------------------------------------------- Date: 2000-Aug-23 17:27 By: tim_one Comment: What do you mean you didn't know it was assigned to you? It was assigned to you for an entire 7 minutes before I reassigned it to me ! So I assigned it back to you. You're indeed right about the fix -- I had hallucinated this into something deeper than it was. Better for you to fix it since you can actually test it! Thanks, Trent. ------------------------------------------------------- Date: 2000-Aug-31 08:49 By: tmick Comment: I am confident that this is fixed I just can't test it because my Win64 box is currently down. I'll leave it open and close it when I get a change to verify (a week or two from now). ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110644&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:15:50 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:15:50 -0700 Subject: [Python-bugs-list] [Bug #110619] urllib.py fails with username/password proxies (PR#221) Message-ID: <200008311715.KAA09286@bush.i.sourceforge.net> Bug #110619, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Library Status: Open Resolution: None Bug Group: Feature Request Priority: 4 Summary: urllib.py fails with username/password proxies (PR#221) Details: Jitterbug-Id: 221 Submitted-By: tarka@zip.com.au Date: Tue, 29 Feb 2000 19:15:45 -0500 (EST) Version: 1.5.2 OS: Irix urllib.py fails to handle proxies with user and password information included in the proxy URL, e.g. http://ssmith:testpass@10.11.12.13:1234 The following example ... import os, urllib os.environ['http_proxy'] = "http://ssmith:testpass01@10.11.12.13:1234" f = urllib.urlopen('http://www.python.org') data = f.read() print data fails with the following errors : Traceback (innermost last): File "url.py", line 3, in ? f = urllib.urlopen('http://www.python.org') File "/var/share//lib/python1.5/urllib.py", line 59, in urlopen return _urlopener.open(url) File "/var/share//lib/python1.5/urllib.py", line 157, in open return getattr(self, name)(url) File "/var/share//lib/python1.5/urllib.py", line 253, in open_http h = httplib.HTTP(host) File "/var/share//lib/python1.5/httplib.py", line 51, in __init__ if host: self.connect(host, port) File "/var/share//lib/python1.5/httplib.py", line 75, in connect raise socket.error, "nonnumeric port" IOError: [Errno socket error] nonnumeric port ==================================================================== Audit trail: Mon May 22 17:35:04 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-31 10:15 By: fdrake Comment: Will be documented as a limitation in the implementation, as suggested in bug #111725. I'm converting this to a feature request that can be dealt with in a subsequent version of Python. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110619&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:24:57 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:24:57 -0700 Subject: [Python-bugs-list] [Bug #111725] Response to bug 110619 Message-ID: <200008311724.KAA04091@delerium.i.sourceforge.net> Bug #111725, was updated on 2000-Aug-11 15:30 Here is a current snapshot of the bug. Project: Python Category: Documentation Status: Closed Resolution: Fixed Bug Group: None Priority: 5 Summary: Response to bug 110619 Details: It probably should be documented somewhere that for urllib, proxies will not work in the environment variable http_proxy The code looks at http://usr:pwd@com:8080 and parses the pwd@com:8080 as a port number and fails. It also ignores the proxy details here. If the proxy details are put into the url, as argument to urlopen, they still don't work, although they are parsed correctly. I'm behind a firewall and this bugged me for some time, as I always received a http error code of 407. Afyter some research of the protocol, etc. I finally resolved it by modifying urllib in the open_http method and changed the line: if auth: h.putheader('Authorization',... to if auth: h.putheader('Proxy-Authorization',... and it worked! Needless to say, whatever aspect of the http protocol requires this to be 'Authorization' will of course now fail for my version of urllib, but at least the proxy part functions correctly. Sorry I can't give any better details as I am not an http guru, just fumbling along! Hope this helps. Cheers, Perry Faulkner (Perry.Faulkner@macquarie.com.au) Follow-Ups: Date: 2000-Aug-25 11:01 By: jhylton Comment: Looks like this is a documentation request. ------------------------------------------------------- Date: 2000-Aug-31 10:24 By: fdrake Comment: Modified documentation to clarify this behavior and note that this is an implementation limitation. This should be fixed in some future version; the original bug report has been marked as a feature request. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=111725&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:33:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:33:09 -0700 Subject: [Python-bugs-list] [Bug #110840] -with-cxx option to configure script (PR#24) Message-ID: <200008311733.KAA04515@delerium.i.sourceforge.net> Bug #110840, was updated on 2000-Aug-01 14:15 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: Later Bug Group: Feature Request Priority: 5 Summary: -with-cxx option to configure script (PR#24) Details: Jitterbug-Id: 24 Submitted-By: guido@python.org Date: Wed, 14 Jul 1999 11:16:51 -0400 (EDT) Version: 1.5.2 OS: Unix Geoff Furnish has a patch for the configure script which might be reasonable. See http://www.python.org/sigs/c++-sig/sig_code.html ==================================================================== Audit trail: Wed Jul 14 11:18:10 1999 guido moved from incoming to request Follow-Ups: Date: 2000-Aug-31 10:33 By: fdrake Comment: Patch is old; needs to be updated relative to the current state of build control. May need to be modified to suit recent versions of CXX (not sure on that one). I'll post a message to the C++ SIG to see what the current state of this work is. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110840&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:45:31 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:45:31 -0700 Subject: [Python-bugs-list] [Bug #113243] missing hyphen in command-line help Message-ID: <200008311745.KAA10422@bush.i.sourceforge.net> Bug #113243, was updated on 2000-Aug-31 10:45 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: Not a Bug Priority: 5 Summary: missing hyphen in command-line help Details: When I do "python -h" on version 1.5.2., I get: ... -X : disable class based built-in exceptions ... This should be "...class-based..." (hyphen included) (Perhaps this has already been fixed in a newer version.) Sorry to bug you guys with such trivia. Thanks again for everybody's great work on Python! perfectionistic-ly y'rs, =g2 For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113243&group_id=5470 From noreply@sourceforge.net Thu Aug 31 18:50:09 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 10:50:09 -0700 Subject: [Python-bugs-list] [Bug #113243] missing hyphen in command-line help Message-ID: <200008311750.KAA05153@delerium.i.sourceforge.net> Bug #113243, was updated on 2000-Aug-31 10:45 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Invalid Bug Group: Not a Bug Priority: 5 Summary: missing hyphen in command-line help Details: When I do "python -h" on version 1.5.2., I get: ... -X : disable class based built-in exceptions ... This should be "...class-based..." (hyphen included) (Perhaps this has already been fixed in a newer version.) Sorry to bug you guys with such trivia. Thanks again for everybody's great work on Python! perfectionistic-ly y'rs, =g2 Follow-Ups: Date: 2000-Aug-31 10:50 By: fdrake Comment: There is no longer a -X option, so this bug no longer exists. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113243&group_id=5470 From noreply@sourceforge.net Thu Aug 31 20:05:21 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 12:05:21 -0700 Subject: [Python-bugs-list] [Bug #112558] dictionary lookup does not check exceptions Message-ID: <200008311905.MAA13572@bush.i.sourceforge.net> Bug #112558, was updated on 2000-Aug-23 07:24 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 9 Summary: dictionary lookup does not check exceptions Details: class BadDictKey: def __hash__(self): return hash(self.__class__) def __cmp__(self, other): if isinstance(other, self.__class__): print "raising error" raise RuntimeError, "gotcha" return other The dict lookup code does not check for hash or cmp functions raising an exception. This can lead to a variety of bogus behavior; e.g. the uncaught exception is noticed and raised for the next line. >>> d = {} >>> x1 = BadDictKey() >>> x2 = BadDictKey() >>> d[x1] = 1 >>> d[x2] = 2 raising error >>> print d.keys() Traceback (most recent call last): File "/tmp/dicterr.py", line 8, in __cmp__ raise RuntimeError, "gotcha" RuntimeError: gotcha Follow-Ups: Date: 2000-Aug-24 09:56 By: fdrake Comment: See patch #101277 for a proposed fix & discussion. ------------------------------------------------------- Date: 2000-Aug-31 12:05 By: fdrake Comment: Fixed by patch #101277, checked in as dictobject.c revision 2.63. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112558&group_id=5470 From noreply@sourceforge.net Thu Aug 31 20:13:23 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 12:13:23 -0700 Subject: [Python-bugs-list] [Bug #113254] pre/sre difference breaks pyclbr Message-ID: <200008311913.MAA13905@bush.i.sourceforge.net> Bug #113254, was updated on 2000-Aug-31 12:13 Here is a current snapshot of the bug. Project: Python Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Summary: pre/sre difference breaks pyclbr Details: """ pre and sre deal differently with groups that "do not contribute to the match". Fredrick points out that sre seems to be right but now pyclbr is broken (though easy to fix). This program demonstrates the difference in behavior and the pyclbr breakage. call it "pyclbrbug.py" The name matters because it uses itself as a test case! """ import pre import sre import pyclbr import sys the_re=r""" (?P ^ (?P [ \t]* ) def [ \t]+ (?P [a-zA-Z_] \w* ) [ \t]* \( ) | (?P ^ (?P [ \t]* ) class [ \t]+ (?P [a-zA-Z_] \w* ) [ \t]* (?P \( [^)\n]* \) )? [ \t]* : ) """ eg="class foo: pass" def test( mod ): print "===========", mod.__name__ re=mod.compile(the_re, mod.VERBOSE | mod.DOTALL | mod.MULTILINE) match=re.search( eg ) print match.start( "Method" ) print match.group( "MethodIndent" ) sys.modules["re"]=mod reload( pyclbr ) pyclbr.readmodule_ex("pyclbrbug",["."]) test( pre ) test( sre ) For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=113254&group_id=5470 From noreply@sourceforge.net Thu Aug 31 20:29:05 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 12:29:05 -0700 Subject: [Python-bugs-list] [Bug #112943] infinite recursion bug Message-ID: <200008311929.MAA14492@bush.i.sourceforge.net> Bug #112943, was updated on 2000-Aug-28 08:40 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 9 Summary: infinite recursion bug Details: Hello! PythonWin crashes when trying to run the following code Hello! PythonWin 1.5.2 (build 132) crashes (on WinNT 4.0) on the following code. class X: def __init__(self,x): self.val = x def __add__(x,y): return X(x.val + y.val) def __radd__(x,y): return y + x if __name__ == '__main__': x = X(4) y = 3 + x Follow-Ups: Date: 2000-Aug-28 08:49 By: gvanrossum Comment: Hello! The example causes endless recursion on __radd__. (You should have said "return x+y" there.) Hello! It is still a bug in 2.0b1! Should be fixed. ------------------------------------------------------- Date: 2000-Aug-28 10:33 By: effbot Comment: footnote: with the current CVS version, this one raises a MemoryError (Stack overflow) -- at least on my Windows 95 box. ------------------------------------------------------- Date: 2000-Aug-31 12:29 By: jhylton Comment: Fixed as best we can in the short time before 2.0b1 release: Set the recursion limit much lower, but allow the user to bump it back up if she needs to. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=112943&group_id=5470 From noreply@sourceforge.net Thu Aug 31 20:29:58 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 12:29:58 -0700 Subject: [Python-bugs-list] [Bug #110615] another unbounded recursion bug Message-ID: <200008311929.MAA14510@bush.i.sourceforge.net> Bug #110615, was updated on 2000-Jul-31 14:06 Here is a current snapshot of the bug. Project: Python Category: Core Status: Closed Resolution: Fixed Bug Group: None Priority: 9 Summary: another unbounded recursion bug Details: Jitterbug-Id: 207 Submitted-By: vincent@ldsol.com Date: Wed, 16 Feb 2000 10:31:02 -0500 (EST) Version: 1.5.2 OS: Linux 2.2.x 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, ==================================================================== Audit trail: Wed Feb 23 21:28:40 2000 guido changed notes Wed Feb 23 21:28:40 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Jul-31 14:06 By: none Comment: From: Guido van Rossum Subject: Re: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 10:57:29 -0500 > 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/) ------------------------------------------------------- Date: 2000-Jul-31 14:06 By: none Comment: From: Vincent Renardias Subject: Re: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 16:39:51 +0000 (GMT) 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] ------------------------------------------------------- Date: 2000-Jul-31 14:06 By: none Comment: From: "Tim Peters" Subject: RE: [Python-bugs-list] python dumps core on my script (PR#207) Date: Wed, 16 Feb 2000 20:36:03 -0500 [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. ------------------------------------------------------- Date: 2000-Aug-31 12:29 By: jhylton Comment: Fixed as best we can in time for 2.0b1 release: Set the recursion limit much lower, and allow the user to bump it back up if she needs to. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110615&group_id=5470 From noreply@sourceforge.net Thu Aug 31 22:52:28 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 14:52:28 -0700 Subject: [Python-bugs-list] [Bug #110625] trouble building under Solaris 7 (PR#260) Message-ID: <200008312152.OAA13972@delerium.i.sourceforge.net> Bug #110625, was updated on 2000-Jul-31 14:08 Here is a current snapshot of the bug. Project: Python Category: Build Status: Open Resolution: None Bug Group: Platform-specific Priority: 6 Summary: trouble building under Solaris 7 (PR#260) Details: Jitterbug-Id: 260 Submitted-By: lipman@helix.nih.gov Date: Fri, 31 Mar 2000 18:03:56 -0500 (EST) Version: 1.5.2 OS: Solaris 7 106541-08 When I built Python on my machine: SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10 Python's internal symbols (for instance PySequence_Length) were not included in the dynamic symbol table of the python executable. This prevented the Numerical-15.2 extensions from importing properly. My machine has both the Sun linker (in /usr/ccs/bin) and the GNU linker installed. I use the GNU linker, which is first in the $PATH under which Python was built. A workaround for this problem is to change the following line in Modules/Makefile.pre from LDFLAGS= to LDFLAGS= -export-dynamic This will only work for the GNU linker. ==================================================================== Audit trail: Mon May 22 17:39:59 2000 guido changed notes Mon May 22 17:39:59 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-06 14:25 By: twouters Comment: This might be fixed by newer autoconf ? ------------------------------------------------------- Date: 2000-Aug-30 05:39 By: akuchling Comment: Reassigning to Jeremy, since I lack the time. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110625&group_id=5470 From noreply@sourceforge.net Thu Aug 31 22:53:32 2000 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Aug 2000 14:53:32 -0700 Subject: [Python-bugs-list] [Bug #110675] Pth: test_fork1 fails, test_thread slow (PR#383) Message-ID: <200008312153.OAA13998@delerium.i.sourceforge.net> Bug #110675, was updated on 2000-Jul-31 14:13 Here is a current snapshot of the bug. Project: Python Category: Core Status: Open Resolution: None Bug Group: 3rd Party Priority: 1 Summary: Pth: test_fork1 fails, test_thread slow (PR#383) Details: Jitterbug-Id: 383 Submitted-By: gregor@hoffleit.de Date: Tue, 4 Jul 2000 12:07:06 -0400 (EDT) Version: CVS version (06/04/00) OS: Debian potato (i386) When I use the current CVS version of Python to build on a Debian potato system with GNU Pth 1.2.3 installed, test_fork1 fails with an error (see below), and test_thread takes significantly longer to complete than when I build the same sources with native LinuxThreads. When running test.regrtest.main(), this happens: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import regrtest >>> regrtest.main() test_grammar test_opcodes ... test_extcall test_fcntl test_fork1 test test_fork1 crashed -- exceptions.AssertionError : Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 32, in f time.sleep(SHORTSLEEP) TypeError: illegal argument type for built-in operation Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' Unhandled exception in thread: Traceback (most recent call last): File "./Lib/test/test_fork1.py", line 30, in f alive[id] = os.getpid() AttributeError: 'None' object has no attribute 'getpid' test_format test_gc ... When running test.test_fork1(), I get this: clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_fork1 Traceback (most recent call last): File "", line 1, in ? File "./Lib/test/test_fork1.py", line 68, in ? main() File "./Lib/test/test_fork1.py", line 44, in main assert a == range(NUM_THREADS) AssertionError >>> test_thread takes very long to complete (5 min compared to 40 sec with LinuxThreads); when you look at the following log, you'll see that it tends to calls the threads serially !? clapton:3> LD_LIBRARY_PATH=`pwd` ./python Python 2.0b1 (#0, Jul 4 2000, 17:06:15) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> from test import test_thread creating task 1 creating task 2 creating task 3 task 1 will run for 2.1 sec task 1 done creating task 4 task 2 will run for 3.2 sec creating task 5 task 2 done creating task task 3 will run for 9.1 6 sec task 3 done creating task 7 task 4 will run for 2.5 sec task 4 done creating task 8 task 5 will run for 0.9 sec task 5 done creating task 9 task 6 will run for 7.4 sec task 6 done creating task 10 waiting for all tasks to complete task 7 will run for 5.3 sec task 7 done task 8 will run for 2.6 sec task 8 done task 9 will run for 2.7 sec task 9 done task 10 will run for 0.9 sec task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 0 entering barrier 0 task 1 will run for 6.2 sec task 1 entering barrier 0 task 7 will run for 7.0 sec task 7 entering barrier 0 task 3 will run for 5.9 sec task 3 entering barrier 0 task 4 will run for 4.5 sec task 4 entering barrier 0 task 5 will run for 9.2 sec task 5 entering barrier 0 task 6 will run for 1.4 sec task 6 entering barrier 0 task 2 will run for 6.0 sec task 2 entering barrier 0 task 8 will run for 2.4 sec task 8 entering barrier 0 task 9 will run for 9.6 sec task 9 entering barrier 0 task 9 leaving barrier 0 task 0 leaving barrier 0 task task 1 leaving barrier 0 0 will run for 0.0 sec task 0 entering barrier 1 task 7 leaving barrier 0 task 9 will run for 0.8 sec task 9 entering barrier task 3 leaving barrier 0 1 task 1 task 4 leaving barrier 0 will run for 6.1 sec task 5 leaving barrier 0 task 1 entering barrier 1 task 6 leaving barrier 0 task 7 will run for 7.9 sec task 2 leaving barrier 0 task 7 entering barrier 1 task 3 task 8 leaving barrier 0 will run for 7.8 sec task 3 entering barrier 1 task 4 will run for 5.7 sec task 4 entering barrier 1 task 5 will run for 2.0 sec task 5 entering barrier 1 task 6 will run for 0.5 sec task 6 entering barrier 1 task 2 will run for 7.4 sec task 2 entering barrier 1 task 8 will run for 1.0 sec task 8 entering barrier 1 task 8 leaving barrier 1 task 7 leaving barrier 1 task 9 leaving barrier 1 task 1 leaving barrier 1 task 8 will run for 6.9 sec task 0 leaving barrier 1 task 8 entering barrier 2 task 0 will run for task 4 leaving barrier 1 0.0 sec task 7 will run for 4.3 sec task 0 entering barrier 2 task 3 leaving barrier 1 task 7 entering barrier 2 task 5 leaving barrier 1 task 6 leaving barrier 1 task 9 will run for 8.2 sec task task 2 leaving barrier 9 entering barrier 2 1 task 5 will run for 8.9 sec task 5 entering barrier 2 task 2 will run for 8.3 sec task 2 entering barrier 2 task 3 will run for 4.5 sec task 3 entering barrier 2 task 1 will run for 7.0 sec task 1 entering barrier 2 task 6 will run for 1.9 sec task 6 entering barrier 2 task 4 will run for 0.2 sec task 4 entering barrier 2 task 4 leaving barrier 2 task 8 leaving barrier 2 task 9 leaving barrier 2 task 7 leaving barrier 2 task 5 leaving barrier 2 task 0 leaving barrier 2 task 2 leaving barrier 2 task 3 leaving barrier 2 task 1 leaving barrier 2 task 6 leaving barrier 2 all tasks done while this is the log of the same test with Python 1.5.2 and LinuxThreads: clapton:3> python Python 1.5.2 (#0, Apr 3 2000, 14:46:48) [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from test import test_thread creating task 1 creating task 2 creating task 3 creating task 4 creating task 5 creating task 6 creating task 7 creating task 8 creating task 9 creating task 10 waiting for all tasks to complete task 1 will run for 8.9 sec task 2 will run for 8.3 sec task 3 will run for 9.1 sec task 5 will run for 6.0 sec task 4 will run for 7.5 sec task 6 will run for 4.7 sec task 7 will run for 4.2 sec task 8 will run for 7.0 sec task 9 will run for 8.7 sec task 10 will run for 9.5 sec task 7 done task 6 done task 5 done task 8 done task 4 done task 2 done task 9 done task 1 done task 3 done task 10 done all tasks done *** Barrier Test *** task 0 will run for 0.0 sec task 1 will run for 2.8 sec task 0 entering barrier 0 task 2 will run for 5.3 sec task 3 will run for 9.2 sec task 5 will run for 8.0 sec task 4 will run for 8.9 sec task 6 will run for 5.0 sec task 7 will run for 1.3 sec task 8 will run for 5.6 sec task 9 will run for 4.7 sec task 7 entering barrier 0 task 1 entering barrier 0 task 9 entering barrier 0 task 6 entering barrier 0 task 2 entering barrier 0 task 8 entering barrier 0 task 5 entering barrier 0 task 4 entering barrier 0 task 3 entering barrier 0 task 3 leaving barrier 0 task 3 will run for 0.1 sec task 0 leaving barrier 0 task 0 will run for 0.0 sec task 7 leaving barrier 0 task 7 will run for 6.6 sec task 1 leaving barrier 0 task 1 will run for 1.0 sec task 9 leaving barrier 0 task 9 will run for 8.2 sec task 6 leaving barrier 0 task 6 will run for 1.0 sec task 2 leaving barrier 0 task 2 will run for 9.2 sec task 8 leaving barrier 0 task 8 will run for 4.4 sec task 5 leaving barrier 0 task 5 will run for 9.6 sec task 4 leaving barrier 0 task 4 will run for 1.7 sec task 0 entering barrier 1 task 3 entering barrier 1 task 1 entering barrier 1 task 6 entering barrier 1 task 4 entering barrier 1 task 8 entering barrier 1 task 7 entering barrier 1 task 9 entering barrier 1 task 2 entering barrier 1 task 5 entering barrier 1 task 5 leaving barrier 1 task 5 will run for 6.6 sec task 0 leaving barrier 1 task 0 will run for 0.0 sec task 3 leaving barrier 1 task 3 will run for 8.5 sec task 1 leaving barrier 1 task 1 will run for 0.1 sec task 6 leaving barrier 1 task 6 will run for 4.7 sec task 4 leaving barrier 1 task 4 will run for 4.7 sec task 8 leaving barrier 1 task 8 will run for 1.7 sec task 7 leaving barrier 1 task 7 will run for 1.8 sec task 9 leaving barrier 1 task 9 will run for 2.8 sec task 2 leaving barrier 1 task 2 will run for 3.3 sec task 0 entering barrier 2 task 1 entering barrier 2 task 8 entering barrier 2 task 7 entering barrier 2 task 9 entering barrier 2 task 2 entering barrier 2 task 6 entering barrier 2 task 4 entering barrier 2 task 5 entering barrier 2 task 3 entering barrier 2 task 3 leaving barrier 2 task 0 leaving barrier 2 task 1 leaving barrier 2 task 8 leaving barrier 2 task 7 leaving barrier 2 task 9 leaving barrier 2 task 2 leaving barrier 2 task 6 leaving barrier 2 task 4 leaving barrier 2 task 5 leaving barrier 2 all tasks done >>> ==================================================================== Audit trail: Tue Jul 11 08:24:22 2000 guido moved from incoming to open Follow-Ups: Date: 2000-Aug-23 10:31 By: jhylton Comment: Another report of test_fork1 problems. Plan to resolve before 2.0b1. ------------------------------------------------------- Date: 2000-Aug-23 10:36 By: tim_one Comment: Jeremy, my chances of helping someone with a problem specific to "Debian potato system with GNU Pth 1.2.3" are nil. Assigned back to you since you seem to believe it's feasible . ------------------------------------------------------- Date: 2000-Aug-31 14:53 By: jhylton Comment: Haven't heard back from the submittor. This sounds like a problem with a buggy GNU Pth package; not a Python bug. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=110675&group_id=5470