From ellement@sdd.hp.com Thu Dec 2 19:05:10 1999 From: ellement@sdd.hp.com (ellement@sdd.hp.com) Date: Thu, 2 Dec 1999 14:05:10 -0500 (EST) Subject: [Python-bugs-list] test_array.py fails (PR#143) Message-ID: <199912021905.OAA27890@python.org> 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? From guido@CNRI.Reston.VA.US Thu Dec 2 19:07:42 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 2 Dec 1999 14:07:42 -0500 (EST) Subject: [Python-bugs-list] test_array.py fails (PR#143) Message-ID: <199912021907.OAA27938@python.org> > 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/) From robert.harrison@pnl.gov Fri Dec 3 06:35:21 1999 From: robert.harrison@pnl.gov (robert.harrison@pnl.gov) Date: Fri, 3 Dec 1999 01:35:21 -0500 (EST) Subject: [Python-bugs-list] complexobject.c optimization error on SGI (PR#144) Message-ID: <199912030635.BAA17503@python.org> Full_Name: Robert J. Harrison Version: 1.5.2 OS: IRIX64 6.5 Submission from: kenn1109.bossig.com (208.26.241.109) 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. From gpk@bell-labs.com Fri Dec 3 15:08:39 1999 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Fri, 3 Dec 1999 10:08:39 -0500 (EST) Subject: [Python-bugs-list] test_popen2 fails (PR#145) Message-ID: <199912031508.KAA03016@python.org> Full_Name: Greg Kochanski Version: 1.5.2 OS: Solaris 2.6 Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) Using a two-processor Ultra-2 running Solaris 2.6 with current patches. CC='cc -mt' ./configure --with-thread --with-solaris change OPT in makefile from -O to -xO3 fiddle with Module/Setup make make test After that, test_popen2 fails. All other tests succeed. "test test_popen2 crashed -- exceptions.AssertionError : " The same crash occurs when optimization is left alone. A context diff between Module/Setup.in and Module/Setup follows: *** Setup.in Wed Mar 24 14:03:56 1999 --- Setup Fri Dec 3 09:23:47 1999 *************** *** 112,118 **** # modules are to be built as shared libraries (see above for more # detail; also note that *static* reverses this effect): ! #*shared* # GNU readline. Unlike previous Python incarnations, GNU readline is # now incorporated in an optional module, configured in the Setup file --- 112,118 ---- # modules are to be built as shared libraries (see above for more # detail; also note that *static* reverses this effect): ! *shared* # GNU readline. Unlike previous Python incarnations, GNU readline is # now incorporated in an optional module, configured in the Setup file *************** *** 158,164 **** # Some more UNIX dependent modules -- off by default, since these # are not supported by all UNIX systems: ! #nis nismodule.c # Sun yellow pages -- not everywhere #termios termios.c # Steen Lumholt's termios module #resource resource.c # Jeremy Hylton's rlimit interface --- 158,164 ---- # Some more UNIX dependent modules -- off by default, since these # are not supported by all UNIX systems: ! nis nismodule.c # Sun yellow pages -- not everywhere #termios termios.c # Steen Lumholt's termios module #resource resource.c # Jeremy Hylton's rlimit interface *************** *** 167,174 **** # These don't work for 64-bit platforms!!! # These represent audio samples or images as strings: ! #audioop audioop.c # Operations on audio samples ! #imageop imageop.c # Operations on images #rgbimg rgbimgmodule.c # Read SGI RGB image files (but coded portably) --- 167,174 ---- # These don't work for 64-bit platforms!!! # These represent audio samples or images as strings: ! audioop audioop.c # Operations on audio samples ! imageop imageop.c # Operations on images #rgbimg rgbimgmodule.c # Read SGI RGB image files (but coded portably) *************** *** 258,264 **** # SunOS specific modules -- off by default: ! #sunaudiodev sunaudiodev.c # George Neville-Neil's timing module: --- 258,264 ---- # SunOS specific modules -- off by default: ! sunaudiodev sunaudiodev.c # George Neville-Neil's timing module: *************** *** 313,319 **** # Lance Ellinghaus's modules: ! rotor rotormodule.c # enigma-inspired encryption #syslog syslogmodule.c # syslog daemon interface --- 313,319 ---- # Lance Ellinghaus's modules: ! #rotor rotormodule.c # enigma-inspired encryption #syslog syslogmodule.c # syslog daemon interface *************** *** 352,358 **** # Anthony Baxter's gdbm module. GNU dbm(3) will require -lgdbm: ! #gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib -lgdbm # Berkeley DB interface. --- 352,358 ---- # Anthony Baxter's gdbm module. GNU dbm(3) will require -lgdbm: ! gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib -lgdbm # Berkeley DB interface. *************** *** 395,407 **** # For Solaris with SunPro compiler (tested on Solaris 2.5 with SunPro C 4.2): # (Without the compiler you don't have -lsunmath.) ! #fpectl fpectlmodule.c -R/opt/SUNWspro/lib -lsunmath -lm # For other systems: see instructions in fpectlmodule.c. #fpectl fpectlmodule.c ... # Test module for fpectl. No extra libraries needed. ! #fpetest fpetestmodule.c # Andrew Kuchling's zlib module. # This require zlib 1.1.3 (or later). --- 395,407 ---- # For Solaris with SunPro compiler (tested on Solaris 2.5 with SunPro C 4.2): # (Without the compiler you don't have -lsunmath.) ! fpectl fpectlmodule.c -R/opt/SUNWspro/lib -lsunmath -lm # For other systems: see instructions in fpectlmodule.c. #fpectl fpectlmodule.c ... # Test module for fpectl. No extra libraries needed. ! fpetest fpetestmodule.c # Andrew Kuchling's zlib module. # This require zlib 1.1.3 (or later). From gpk@bell-labs.com Fri Dec 3 15:47:33 1999 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Fri, 3 Dec 1999 10:47:33 -0500 (EST) Subject: [Python-bugs-list] Re: test_popen2 fails (PR#145) Message-ID: <199912031547.KAA04604@python.org> Guido van Rossum wrote: > > This is a duplicate of PR#49, see the bugs list. (search it for test_popen2) So it is. It works when patched. Sorry that I missed it, and thanks. From taliesin@nvg.org Fri Dec 3 17:05:52 1999 From: taliesin@nvg.org (taliesin@nvg.org) Date: Fri, 3 Dec 1999 12:05:52 -0500 (EST) Subject: [Python-bugs-list] Re: mktime fails on specific dates (PR#139) Message-ID: <199912031705.MAA07109@python.org> * Guido van Rossum (bugs-py@python.org) [991203 16:38]: > > I was comparing dates the other day... > > /snippage most what I said/ > > Possible fixes: > > - time-module sets TZ to UCT before calling mktime > > - never use localtime on a machine :) > > > > Please look into it or mention it clearly in the docs :) > > Not sure what you want us to do. That local time doesn't exist, > so an error is appropriate. The OverflowError is documented in > http://www.python.org/doc/current/lib/module-time.html. You don't think it's a silly, unnecessary gotcha? It would be very nice to *not* have to write umpteen different versions of a teeny function in a teeny proggie to have it work on more than one platform, not to mention the necessary "figure-out-what-os-we're-on-today"-logic. Not having to check the source-code for your os to figure out why something dies would be nice too :) Side-effect of wrapping the c-functions I guess. Calling timegm() instead of mktime() in time_mktime() in the time-module prevents it on FreeBSD at least, as timegm() doesn't care about timezones and dst at all... tal. From guido@CNRI.Reston.VA.US Fri Dec 3 17:16:43 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Fri, 3 Dec 1999 12:16:43 -0500 (EST) Subject: [Python-bugs-list] Re: mktime fails on specific dates (PR#139) Message-ID: <199912031716.MAA07385@python.org> > * Guido van Rossum (bugs-py@python.org) [991203 16:38]: > > > I was comparing dates the other day... > > > > /snippage most what I said/ > > > Possible fixes: > > > - time-module sets TZ to UCT before calling mktime > > > - never use localtime on a machine :) > > > > > > Please look into it or mention it clearly in the docs :) > > > > Not sure what you want us to do. That local time doesn't exist, > > so an error is appropriate. The OverflowError is documented in > > http://www.python.org/doc/current/lib/module-time.html. > > You don't think it's a silly, unnecessary gotcha? It would be very nice > to *not* have to write umpteen different versions of a teeny function in > a teeny proggie to have it work on more than one platform, not to > mention the necessary "figure-out-what-os-we're-on-today"-logic. Not > having to check the source-code for your os to figure out why something dies > would be nice too :) Side-effect of wrapping the c-functions I guess. There's no need to know what platform you're on. Just know that you may have to catch an exception. That some platforms don't raise the exception shouldn't bother you. Look at it from my side. I know that mktime() can return an error. What's more logical than to translate that error into an exception in the wrapper? > Calling timegm() instead of mktime() in time_mktime() in the time-module > prevents it on FreeBSD at least, as timegm() doesn't care about > timezones and dst at all... Of course, since timegm() is supposed to work in GMT (UTC). If you look at the C man page, mktime() is supposed to work in local time. So calling timegm() would be wrong. I still don't see what I can do to alleviate the pain. Remember, I don't create the problem, I just pass it on. Time manipulation software is a bitch to write, so like to use the standard (!) C library where I can. --Guido van Rossum (home page: http://www.python.org/~guido/) From dgudeman@azstarnet.com Fri Dec 3 23:11:14 1999 From: dgudeman@azstarnet.com (dgudeman@azstarnet.com) Date: Fri, 3 Dec 1999 18:11:14 -0500 (EST) Subject: [Python-bugs-list] bugs in xmllib (PR#146) Message-ID: <199912032311.SAA17404@python.org> Full_Name: Dave Gudeman Version: 1.52 OS: all (only verified on Windows 95) Submission from: dialup19ip095.tus.azstarnet.com (169.197.39.95) Please send email to confirm that you received this... I have found 2.5 bugs in xmllib.py and am contributing a patch for 1.5 of them. Bug #1 (fixed in patch): handle_entityref() is never called. Bug #1.5 (addressed in patch): handle_entityref() doesn't handle the built-in named character refs correctly. It passes them on to handle_data() as an unresolved charref. This is half a bug because it isn't a bug until you apply the patch to fix #1. Also, whoever maintains xmllib may not like my fix for this one because I just skip the call to handle_charref(). I don't think it should be called in this case, but reasonable people may differ. Bug #2: The documentation states that handle_doctype() takes two arguments but it really takes 4. I think the correct solution to this is to fix the doc, not the function. Sorry, my windows diff will not produce context diffs, but this is pretty trivial: 333,340c333 < if self.entitydefs.has_key(name): < self.rawdata = rawdata = rawdata[:res.start(0)] + self.entitydefs[name] + rawdata[i:] < n = len(rawdata) < i = res.start(0) < else: < self.syntax_error("reference to unknown entity `&%s;'" % name) < self.unknown_entityref(name) < self.lineno = self.lineno + string.count(res.group(0), '\n') --- > self.handle_entityref(name) 706,710c707,711 < entitydefs = {'lt': '<', # must use charref < 'gt': '>', < 'amp': '&', # must use charref < 'quot': '"', < 'apos': ''', --- > entitydefs = {'lt': '<', # must use charref > 'gt': '>', > 'amp': '&', # must use charref > 'quot': '"', > 'apos': "'", I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so. I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation. From dgudeman@azstarnet.com Fri Dec 3 23:17:06 1999 From: dgudeman@azstarnet.com (dgudeman@azstarnet.com) Date: Fri, 3 Dec 1999 18:17:06 -0500 (EST) Subject: [Python-bugs-list] StringIO does not write integers (PR#147) Message-ID: <199912032317.SAA17501@python.org> Full_Name: Dave Gudeman Version: 1.52 OS: windows 95 Submission from: dialup19ip095.tus.azstarnet.com (169.197.39.95) The following program demonstrates an inconsistency in StringIO: from StringIO import * out = StringIO() out.write(3) This causes an error message, which is inconsistent with sys.stdout.write(3), which writes out a "3". From tim_one@email.msn.com Sat Dec 4 03:44:17 1999 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 3 Dec 1999 22:44:17 -0500 Subject: [Python-bugs-list] StringIO does not write integers (PR#147) In-Reply-To: <199912032317.SAA17501@python.org> Message-ID: <000901bf3e09$d76966a0$2ca0143f@tim> > Full_Name: Dave Gudeman > Version: 1.52 > OS: windows 95 > Submission from: dialup19ip095.tus.azstarnet.com (169.197.39.95) > > > The following program demonstrates an inconsistency in StringIO: > > from StringIO import * > out = StringIO() > out.write(3) > > This causes an error message, which is inconsistent with > sys.stdout.write(3), which writes out a "3". Not unless you've rebound sys.stdout to something other than its default! >>> import sys >>> sys.stdout.write(3) Traceback (innermost last): File "", line 1, in ? TypeError: read-only buffer, int >>> Python has very few implicit type conversions, and it would make no sense for a .write() method to accept an integer -- it requires a character buffer (most commonly a string). The error msg produced here is trying to say that, although it could sure stand some humanization. Perhaps you're thinking of the "print" stmt? That magically applies str() to its arguments before invoking sys.stdout.write. From tim_one@email.msn.com Sat Dec 4 03:45:22 1999 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Fri, 3 Dec 1999 22:45:22 -0500 (EST) Subject: [Python-bugs-list] StringIO does not write integers (PR#147) Message-ID: <199912040345.WAA22440@python.org> > Full_Name: Dave Gudeman > Version: 1.52 > OS: windows 95 > Submission from: dialup19ip095.tus.azstarnet.com (169.197.39.95) > > > The following program demonstrates an inconsistency in StringIO: > > from StringIO import * > out = StringIO() > out.write(3) > > This causes an error message, which is inconsistent with > sys.stdout.write(3), which writes out a "3". Not unless you've rebound sys.stdout to something other than its default! >>> import sys >>> sys.stdout.write(3) Traceback (innermost last): File "", line 1, in ? TypeError: read-only buffer, int >>> Python has very few implicit type conversions, and it would make no sense for a .write() method to accept an integer -- it requires a character buffer (most commonly a string). The error msg produced here is trying to say that, although it could sure stand some humanization. Perhaps you're thinking of the "print" stmt? That magically applies str() to its arguments before invoking sys.stdout.write. From flight@mathi.uni-heidelberg.de Sat Dec 4 11:49:39 1999 From: flight@mathi.uni-heidelberg.de (flight@mathi.uni-heidelberg.de) Date: Sat, 4 Dec 1999 06:49:39 -0500 (EST) Subject: [Python-bugs-list] Jitterbug cumbersome to use with offline cache (PR#148) Message-ID: <199912041149.GAA01593@python.org> --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'd like to "mirror" python-bugs for offline reading. While the pages are really quite static and it should be easy to mirror them, Jitterbug tends to make the URLs more complex than necessary, so that a single page is accessed via many different URLs: E.g. the first page with "notabug" reports currently has those URLs, which always led to the same page: http://www.python.org/python-bugs/notabug?user=3Dguest http://www.python.org/python-bugs/notabug?page=3D0;user=3Dguest =20 http://www.python.org/python-bugs/notabug?page=3D0;page=3D1;user=3Dguest http://www.python.org/python-bugs/notabug?page=3D0;page=3D2;user=3Dguest http://www.python.org/python-bugs/notabug Even worse, the navigation is sometimes quite strange: If you're on the second "notabug" page and click e.g. on "request" in the headline, you get to the second "request" page. I'd expect to get on the first page of the new section. I don't know if this is a problem of this installation of Jitterbug, or if it is a problem of Jitterbug itself. In the later case, I think we should notify the Jitterbug maintainers of this shortcoming. Gregor =20 --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE4SEva3eVfDf25G40RAWCwAJ4qpdV8RHaBLrzT1pgpaVM5g+rJ8QCgrd8S W+VCGLgPB8BH/Aru4po46EQ= =7iBw -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From dgudeman@azstarnet.com Sun Dec 5 01:15:10 1999 From: dgudeman@azstarnet.com (Dave Gudeman) Date: Sat, 04 Dec 1999 18:15:10 -0700 Subject: [Python-bugs-list] StringIO does not write integers (PR#147) References: <000901bf3e09$d76966a0$2ca0143f@tim> Message-ID: <3849BC9E.C4F58005@azstarnet.com> Tim Peters wrote: > > Full_Name: Dave Gudeman > > Version: 1.52 > > OS: windows 95 > > Submission from: dialup19ip095.tus.azstarnet.com (169.197.39.95) > > > > > > The following program demonstrates an inconsistency in StringIO: > > > > from StringIO import * > > out = StringIO() > > out.write(3) > > > > This causes an error message, which is inconsistent with > > sys.stdout.write(3), which writes out a "3". > > Not unless you've rebound sys.stdout to something other than its default! > > >>> import sys > >>> sys.stdout.write(3) > Traceback (innermost last): > File "", line 1, in ? > TypeError: read-only buffer, int > >>> > > Python has very few implicit type conversions, and it would make no sense > for a .write() method to accept an integer -- it requires a character buffer > (most commonly a string). The error msg produced here is trying to say > that, although it could sure stand some humanization. > > Perhaps you're thinking of the "print" stmt? That magically applies str() > to its arguments before invoking sys.stdout.write. Guido had it right, I'm using IDLE. Actually, I thought from the tutorial that it shouldn't work, but it did when I used it by mistake, that's why I called it an "inconsistency" rather than a bug. Sorry to "bug" everyone... And thanks for setting up the bug report form on the web page. From dgudeman@azstarnet.com Sun Dec 5 01:05:20 1999 From: dgudeman@azstarnet.com (dgudeman@azstarnet.com) Date: Sat, 4 Dec 1999 20:05:20 -0500 (EST) Subject: [Python-bugs-list] StringIO does not write integers (PR#147) Message-ID: <199912050105.UAA16091@python.org> Tim Peters wrote: > > Full_Name: Dave Gudeman > > Version: 1.52 > > OS: windows 95 > > Submission from: dialup19ip095.tus.azstarnet.com (169.197.39.95) > > > > > > The following program demonstrates an inconsistency in StringIO: > > > > from StringIO import * > > out = StringIO() > > out.write(3) > > > > This causes an error message, which is inconsistent with > > sys.stdout.write(3), which writes out a "3". > > Not unless you've rebound sys.stdout to something other than its default! > > >>> import sys > >>> sys.stdout.write(3) > Traceback (innermost last): > File "", line 1, in ? > TypeError: read-only buffer, int > >>> > > Python has very few implicit type conversions, and it would make no sense > for a .write() method to accept an integer -- it requires a character buffer > (most commonly a string). The error msg produced here is trying to say > that, although it could sure stand some humanization. > > Perhaps you're thinking of the "print" stmt? That magically applies str() > to its arguments before invoking sys.stdout.write. Guido had it right, I'm using IDLE. Actually, I thought from the tutorial that it shouldn't work, but it did when I used it by mistake, that's why I called it an "inconsistency" rather than a bug. Sorry to "bug" everyone... And thanks for setting up the bug report form on the web page. From python.org@netfinances.com Sun Dec 5 03:03:46 1999 From: python.org@netfinances.com (python.org@netfinances.com) Date: Sat, 4 Dec 1999 22:03:46 -0500 (EST) Subject: [Python-bugs-list] strptime error (PR#149) Message-ID: <199912050303.WAA17856@python.org> Full_Name: Fred Fahnert Version: 1.5.2 OS: RedHat Linux 6.0 Submission from: host162.netfinances.com (216.65.99.162) 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 >>> From guido@CNRI.Reston.VA.US Mon Dec 6 14:46:53 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Mon, 06 Dec 1999 09:46:53 -0500 Subject: [Python-bugs-list] Jitterbug cumbersome to use with offline cache (PR#148) In-Reply-To: Your message of "Sat, 04 Dec 1999 06:49:39 EST." <199912041149.GAA01593@python.org> References: <199912041149.GAA01593@python.org> Message-ID: <199912061446.JAA18779@eric.cnri.reston.va.us> > I'd like to "mirror" python-bugs for offline reading. While the pages are > really quite static and it should be easy to mirror them, Jitterbug tends to > make the URLs more complex than necessary, so that a single page is accessed > via many different URLs: > > E.g. the first page with "notabug" reports currently has those URLs, which > always led to the same page: > > http://www.python.org/python-bugs/notabug?user=3Dguest > http://www.python.org/python-bugs/notabug?page=3D0;user=3Dguest =20 > http://www.python.org/python-bugs/notabug?page=3D0;page=3D1;user=3Dguest > http://www.python.org/python-bugs/notabug?page=3D0;page=3D2;user=3Dguest > http://www.python.org/python-bugs/notabug > > Even worse, the navigation is sometimes quite strange: If you're on the > second "notabug" page and click e.g. on "request" in the headline, you get > to the second "request" page. I'd expect to get on the first page of the new > section. > > > I don't know if this is a problem of this installation of Jitterbug, or if > it is a problem of Jitterbug itself. In the later case, I think we should > notify the Jitterbug maintainers of this shortcoming. I can't check this right now (python.org is having hardware problems) but I think these are all problems with Jitterbug. Our use of it is really very simpleminded. Basically, it stinks, but the other bug reporting systems I've looked at stink worse. Eventually it should be redone in Zope -- feel like a weekend hacking? --Guido van Rossum (home page: http://www.python.org/~guido/) From jam@camros.com Tue Dec 7 05:13:55 1999 From: jam@camros.com (jam@camros.com) Date: Tue, 7 Dec 1999 00:13:55 -0500 (EST) Subject: [Python-bugs-list] Bug with Threaded exceptions? (PR#151) Message-ID: <199912070513.AAA19869@python.org> Full_Name: Jeffrey A. Marshall Version: 1.5.2 OS: solaris 2.6, linux (rh 6.0) Submission from: phantasm.paragon-software.com (204.91.29.130) We've run into a possible bug when using exceptions within a threaded python program. It seems as though objects on the python execution stack are "garbage" collected in a different thread than where the were created. This isn't a real problem, except we're trying to make our developer's life easier by defining classes which have certain (thread-related) semantics associated with their (instance's) life-times. Maybe this problem only shows up due to the fact that we're not catching an exception within our top-level thread function. I've included a script demonstrating the problem below, along with the workaround we're currently using: thanks, -jeff ----- python code follows ------------- import threading # this is the class we've developed to help with # making sure that a given mutex (lock) gets # released, even when exceptions are raised # # The intent is that creating an instance of "BlockLock" # acquires the given lock object # # And that when the BlockLock goes out of scope (or # gets deleted) it automagically releases the lock # class BlockLock: def __init__ (self, lock): self.__lock = lock self.__thread = threading.currentThread () lock.acquire () print "%s.__init__: self=%s thread=%s" % (self.__class__.__name__, self, threading.currentThread ()) def __del__ (self): thr = threading.currentThread () if thr is not self.__thread: print "WARNING: releasing lock in diff. thread (%s)" % (self.__thread,) print "%s.__del__: self=%s thread=%s" % (self.__class__.__name__, self, thr) self.__lock.release () the_lock = threading.Lock () def my_buggy_thread_fun (): # buggy function, showing that the __del__ method in block lock # is a = BlockLock (the_lock) assert 0 def my_fixed_thread_fun (): # Same as above, our workaround is to always place # a `try'/`finally' block around all the code... Doing # this almost defeats the whole purpose of having # the BlockLock class... a = BlockLock (the_lock) try: assert 0 finally: del a def show_bug (): thr = threading.Thread (target=my_buggy_thread_fun) print "starting bad thread: ", `thr` thr.start () thr.join () print "bad thread exited" thr = threading.Thread (target=my_fixed_thread_fun) print "starting fixed thread: ", `thr` thr.start () thr.join () print "fixed thread exited" if __name__ == '__main__': show_bug () From tim_one@email.msn.com Tue Dec 7 05:47:03 1999 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 7 Dec 1999 00:47:03 -0500 Subject: [Python-bugs-list] Bug with Threaded exceptions? (PR#151) In-Reply-To: <199912070513.AAA19869@python.org> Message-ID: <001901bf4076$7d536840$88a0143f@tim> Python defines neither the lifetime of objects nor makes any guarantee about which threads will run finalizers. Just facts of life! Acquiring/releasing a lock in an object ctor/dtor is a C++ idiom that doesn't carry over (C++ doesn't say anything about threads either, but does define the lifetime of local vrbls). It *usually* works OK in CPython, but usually doesn't in JPython. In your particular case, the local vrbl "a" is still alive after function exit because it's still reachable via the traceback object created by the exception. Among other things, the traceback object contains the chain of stack frames (which in turn contain the local vrbls) active at the time the exception was triggered. Binding sys.exc_traceback to, e.g., None will usually make it unreachable again (and so trigger CPython's refcount-based garbage collection of "a"). I don't know of any way around this except using by try/finally in one way or another. In any case, it's not a bug -- it's functioning as designed. From tim_one@email.msn.com Tue Dec 7 05:48:32 1999 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Tue, 7 Dec 1999 00:48:32 -0500 (EST) Subject: [Python-bugs-list] Bug with Threaded exceptions? (PR#151) Message-ID: <199912070548.AAA23487@python.org> Python defines neither the lifetime of objects nor makes any guarantee about which threads will run finalizers. Just facts of life! Acquiring/releasing a lock in an object ctor/dtor is a C++ idiom that doesn't carry over (C++ doesn't say anything about threads either, but does define the lifetime of local vrbls). It *usually* works OK in CPython, but usually doesn't in JPython. In your particular case, the local vrbl "a" is still alive after function exit because it's still reachable via the traceback object created by the exception. Among other things, the traceback object contains the chain of stack frames (which in turn contain the local vrbls) active at the time the exception was triggered. Binding sys.exc_traceback to, e.g., None will usually make it unreachable again (and so trigger CPython's refcount-based garbage collection of "a"). I don't know of any way around this except using by try/finally in one way or another. In any case, it's not a bug -- it's functioning as designed. From jam@camros.com Tue Dec 7 06:12:40 1999 From: jam@camros.com (jam@camros.com) Date: Tue, 7 Dec 1999 01:12:40 -0500 (EST) Subject: [Python-bugs-list] Bug with Threaded exceptions? (PR#151) In-Reply-To: <001901bf4076$7d536840$88a0143f@tim> from "Tim Peters" at Dec 7, 99 00:47:03 am Message-ID: <19991207061240.24583.qmail@grub.paragon-software.com> I Agree that the ctor/dtor is a C++ idiom, we'll re-arange our code to "acquire"/"release" locks instead of trying to do things using an object's ctor/dtor (which as you stated are not reliable when using a non-ref counted vm like JPython). thanks, -jeff > > Python defines neither the lifetime of objects nor makes any guarantee about > which threads will run finalizers. Just facts of life! Acquiring/releasing > a lock in an object ctor/dtor is a C++ idiom that doesn't carry over (C++ > doesn't say anything about threads either, but does define the lifetime of > local vrbls). It *usually* works OK in CPython, but usually doesn't in > JPython. > > In your particular case, the local vrbl "a" is still alive after function > exit because it's still reachable via the traceback object created by the > exception. Among other things, the traceback object contains the chain of > stack frames (which in turn contain the local vrbls) active at the time the > exception was triggered. Binding sys.exc_traceback to, e.g., None will > usually make it unreachable again (and so trigger CPython's refcount-based > garbage collection of "a"). > > I don't know of any way around this except using by try/finally in one way > or another. In any case, it's not a bug -- it's functioning as designed. > > From jam@camros.com Tue Dec 7 06:12:16 1999 From: jam@camros.com (jam@camros.com) Date: Tue, 7 Dec 1999 01:12:16 -0500 (EST) Subject: [Python-bugs-list] Bug with Threaded exceptions? (PR#151) Message-ID: <199912070612.BAA24693@python.org> I Agree that the ctor/dtor is a C++ idiom, we'll re-arange our code to "acquire"/"release" locks instead of trying to do things using an object's ctor/dtor (which as you stated are not reliable when using a non-ref counted vm like JPython). thanks, -jeff > > Python defines neither the lifetime of objects nor makes any guarantee about > which threads will run finalizers. Just facts of life! Acquiring/releasing > a lock in an object ctor/dtor is a C++ idiom that doesn't carry over (C++ > doesn't say anything about threads either, but does define the lifetime of > local vrbls). It *usually* works OK in CPython, but usually doesn't in > JPython. > > In your particular case, the local vrbl "a" is still alive after function > exit because it's still reachable via the traceback object created by the > exception. Among other things, the traceback object contains the chain of > stack frames (which in turn contain the local vrbls) active at the time the > exception was triggered. Binding sys.exc_traceback to, e.g., None will > usually make it unreachable again (and so trigger CPython's refcount-based > garbage collection of "a"). > > I don't know of any way around this except using by try/finally in one way > or another. In any case, it's not a bug -- it's functioning as designed. > > From cjc26@cornell.edu Wed Dec 8 03:55:19 1999 From: cjc26@cornell.edu (cjc26@cornell.edu) Date: Tue, 7 Dec 1999 22:55:19 -0500 (EST) Subject: [Python-bugs-list] math.log(0) dumps core (PR#152) Message-ID: <199912080355.WAA21795@python.org> Full_Name: Cliff Crawford Version: 1.5.2 OS: FreeBSD 3.3-STABLE Submission from: ith1-379.twcny.rr.com (24.24.11.121) math.log(0) and math.log(0.0) both cause the interpreter to dump core. Sample output: bridget:~$ uname -a FreeBSD bridget.mindriot.net 3.3-STABLE FreeBSD 3.3-STABLE #19: Fri Oct 8 20:01:29 EDT 1999 root@tankgrrl.bridget.mindriot.net:/usr/src/sys/compile/CJC26 i386 bridget:~$ python Python 1.5.2 (#25, Jun 21 1999, 18:19:49) [GCC egcs-2.91.60 19981201 (egcs-1.1.1 on freebsd3 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import math >>> math.log(0) Floating point exception (core dumped) From guido@CNRI.Reston.VA.US Wed Dec 8 04:13:34 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 07 Dec 1999 23:13:34 -0500 Subject: [Python-bugs-list] math.log(0) dumps core (PR#152) In-Reply-To: Your message of "Tue, 07 Dec 1999 22:55:19 EST." <199912080355.WAA21795@python.org> References: <199912080355.WAA21795@python.org> Message-ID: <199912080413.XAA29839@eric.cnri.reston.va.us> > Full_Name: Cliff Crawford > Version: 1.5.2 > OS: FreeBSD 3.3-STABLE > Submission from: ith1-379.twcny.rr.com (24.24.11.121) > > > math.log(0) and math.log(0.0) both cause the interpreter to dump core. > Sample output: > > bridget:~$ uname -a > FreeBSD bridget.mindriot.net 3.3-STABLE FreeBSD 3.3-STABLE #19: Fri Oct 8 > 20:01:29 EDT 1999 > root@tankgrrl.bridget.mindriot.net:/usr/src/sys/compile/CJC26 i386 > bridget:~$ python > Python 1.5.2 (#25, Jun 21 1999, 18:19:49) [GCC egcs-2.91.60 19981201 > (egcs-1.1.1 on freebsd3 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import math > >>> math.log(0) > Floating point exception (core dumped) I'm sorry, but this is a bug in the C math library of your platform. The C function is supposed to return an error which Python translates into an exception; on correct platforms the following behavior is observed: >>> import math >>> math.log(0) Traceback (innermost last): File "", line 1, in ? math.log(0) OverflowError: math range error >>> math.log(0.0) Traceback (innermost last): File "", line 1, in ? math.log(0.0) OverflowError: math range error >>> --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Wed Dec 8 04:13:19 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 7 Dec 1999 23:13:19 -0500 (EST) Subject: [Python-bugs-list] math.log(0) dumps core (PR#152) Message-ID: <199912080413.XAA22044@python.org> > Full_Name: Cliff Crawford > Version: 1.5.2 > OS: FreeBSD 3.3-STABLE > Submission from: ith1-379.twcny.rr.com (24.24.11.121) > > > math.log(0) and math.log(0.0) both cause the interpreter to dump core. > Sample output: > > bridget:~$ uname -a > FreeBSD bridget.mindriot.net 3.3-STABLE FreeBSD 3.3-STABLE #19: Fri Oct 8 > 20:01:29 EDT 1999 > root@tankgrrl.bridget.mindriot.net:/usr/src/sys/compile/CJC26 i386 > bridget:~$ python > Python 1.5.2 (#25, Jun 21 1999, 18:19:49) [GCC egcs-2.91.60 19981201 > (egcs-1.1.1 on freebsd3 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> import math > >>> math.log(0) > Floating point exception (core dumped) I'm sorry, but this is a bug in the C math library of your platform. The C function is supposed to return an error which Python translates into an exception; on correct platforms the following behavior is observed: >>> import math >>> math.log(0) Traceback (innermost last): File "", line 1, in ? math.log(0) OverflowError: math range error >>> math.log(0.0) Traceback (innermost last): File "", line 1, in ? math.log(0.0) OverflowError: math range error >>> --Guido van Rossum (home page: http://www.python.org/~guido/) From info@inexchange.net Wed Dec 8 12:57:58 1999 From: info@inexchange.net (info@inexchange.net) Date: Wed, 8 Dec 1999 07:57:58 -0500 (EST) Subject: [Python-bugs-list] Special Webhosting and Dedicated Server Offer (PR#153) Message-ID: <199912081257.HAA08319@python.org> If you wish to be excluded from any future mailings, reply with "remove" in the subject header. ------------------------------------------------------------ http://www.inexchange.net Internet Exchange would like to introduce our Special Hosting and Dedicated Server Plans * Budget Plans from $14.95 Mo. * E-commerce Plans from $49.95 Mo. * Dedicated Server Plan from $99.00 Mo. (Ask about YOUR FREE Server!) * Sign up for 6 months, and we'll WAIVE the setup fee * Sign up for 10 months, and we'll WAIVE the setup fee and give you 2 FREE months * Sign up for 12 months, and we'll give you a FULL FREE 2nd year of hosting * UNLIMITED E-mail, E-mail forwarding, auto responders and vacation reply * FREE registration of your domain with over 950 search engines * Multiple, Redundant, High-Speed connections to the web * INTERNATIONAL Hosting * Access to your account anytime from your own browser * Full Microsoft Front Page support * Unlimited FTP updates * Personal CGI directory for your own scripts (or use ours) * Comprehensive statistics program shows you everything * Domain name registration (www.yourname.com) * Friendly customer support * Additional plans also available If for any reason you are not satisfied with InfoWatch's service after 30 days, we will transfer you back to your original host and pay any transfer fees. http://www.inexchange.net info@inexchange.net From robin@alldunn.com Wed Dec 8 20:03:10 1999 From: robin@alldunn.com (robin@alldunn.com) Date: Wed, 8 Dec 1999 15:03:10 -0500 (EST) Subject: [Python-bugs-list] Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) Message-ID: <199912082003.PAA16894@python.org> > ----- Forwarded message from Guido van Rossum ----- > > Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST) > From: Guido van Rossum > Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) > > > I hit a problem trying to compile wxPython on IRIX 6.5. The issue is NULL > > should be "0" when compiling for C++. The IRIX headers define it this way. > > The Python mymalloc.h header doesn't. A work-around is to require clients > > to include stdio.h before including any Python header files, but this is a > > hack. > > Why is wxPython using mymalloc.h directly? It should use Python.h, > which *does* include stdio.h first. > > > ----- End forwarded message ----- > wxPython does use Python.h and if I remember correctly, moving it to be the first #include (to ensure that none of the wx or my headers were screwing things up) didn't help Randall at all. He had to put an #include before it. -- Robin Dunn Software Craftsman robin@AllDunn.com http://AllDunn.com/robin/ http://AllDunn.com/wxPython/ Check it out! From guido@CNRI.Reston.VA.US Wed Dec 8 22:04:30 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 08 Dec 1999 17:04:30 -0500 Subject: [Python-bugs-list] Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) In-Reply-To: Your message of "Wed, 08 Dec 1999 15:03:10 EST." <199912082003.PAA16894@python.org> References: <199912082003.PAA16894@python.org> Message-ID: <199912082204.RAA04923@eric.cnri.reston.va.us> > > ----- Forwarded message from Guido van Rossum ----- > > > > Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST) > > From: Guido van Rossum > > Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" > (PR#136) > > > > > I hit a problem trying to compile wxPython on IRIX 6.5. The issue is > NULL > > > should be "0" when compiling for C++. The IRIX headers define it this > way. > > > The Python mymalloc.h header doesn't. A work-around is to require > clients > > > to include stdio.h before including any Python header files, but this is > a > > > hack. > > > > Why is wxPython using mymalloc.h directly? It should use Python.h, > > which *does* include stdio.h first. > > > > > > ----- End forwarded message ----- > > > > wxPython does use Python.h and if I remember correctly, moving it to be the > first #include (to ensure that none of the wx or my headers were screwing > things up) didn't help Randall at all. He had to put an #include > before it. Strange. I don't have your source so there's no point arguing about it here. Python.h definitely includes before including "mymalloc.h". At least in 1.5(.x), I haven't checked older versions. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Wed Dec 8 22:04:08 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 8 Dec 1999 17:04:08 -0500 (EST) Subject: [Python-bugs-list] Re: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) Message-ID: <199912082204.RAA19106@python.org> > > ----- Forwarded message from Guido van Rossum ----- > > > > Date: Fri, 3 Dec 1999 10:32:03 -0500 (EST) > > From: Guido van Rossum > > Subject: Re: WebBugRptBroken & "Python mymalloc.h; not C++ compatible" > (PR#136) > > > > > I hit a problem trying to compile wxPython on IRIX 6.5. The issue is > NULL > > > should be "0" when compiling for C++. The IRIX headers define it this > way. > > > The Python mymalloc.h header doesn't. A work-around is to require > clients > > > to include stdio.h before including any Python header files, but this is > a > > > hack. > > > > Why is wxPython using mymalloc.h directly? It should use Python.h, > > which *does* include stdio.h first. > > > > > > ----- End forwarded message ----- > > > > wxPython does use Python.h and if I remember correctly, moving it to be the > first #include (to ensure that none of the wx or my headers were screwing > things up) didn't help Randall at all. He had to put an #include > before it. Strange. I don't have your source so there's no point arguing about it here. Python.h definitely includes before including "mymalloc.h". At least in 1.5(.x), I haven't checked older versions. --Guido van Rossum (home page: http://www.python.org/~guido/) From gpk@bell-labs.com Thu Dec 9 16:43:23 1999 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Thu, 9 Dec 1999 11:43:23 -0500 (EST) Subject: [Python-bugs-list] Trap for perl programmers (PR#154) Message-ID: <199912091643.LAA09261@python.org> Full_Name: Greg Kochanski Version: 1.5.2 OS: Solaris 2.6 Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) string.split(a, b, n) has unexpectedly different behavior from Perl's split, and a note ought to be added somewhere, at least in an FAQ. Specifically, string.split(a, b, n) returns at most n+1 items in a list, while Perl's split returns at most n items. I was confused for a while by this. From guido@CNRI.Reston.VA.US Thu Dec 9 16:58:33 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 9 Dec 1999 11:58:33 -0500 (EST) Subject: [Python-bugs-list] Trap for perl programmers (PR#154) Message-ID: <199912091658.LAA09593@python.org> > Full_Name: Greg Kochanski > Version: 1.5.2 > OS: Solaris 2.6 > Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) > > string.split(a, b, n) has unexpectedly different behavior from Perl's split, > and a note ought to be added somewhere, at least in an FAQ. > > Specifically, string.split(a, b, n) returns at most n+1 items in a list, > while Perl's split returns at most n items. I was confused for a while > by this. I sympathize with your pain. However, do you think you would have had any less pain if there was an FAQ entry about it? The behavior is described clearly in the docs for string.split(), but you probably didn't read it carefully enough to notice the difference. I don't blame you, that's just life. Should we really litter the Python docs with warnings in bold where things differ from their Perl counterparts? Maybe only for a few specific case -- e.g. hex(), which apparently does the opposite of Perl's hex()...? --Guido van Rossum (home page: http://www.python.org/~guido/) From jeremy@cnri.reston.va.us Thu Dec 9 17:11:05 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Thu, 9 Dec 1999 12:11:05 -0500 (EST) Subject: [Python-bugs-list] Trap for perl programmers (PR#154) In-Reply-To: <199912091643.LAA09261@python.org> References: <199912091643.LAA09261@python.org> Message-ID: <14415.58025.776958.930324@goon.cnri.reston.va.us> I think the right approach here is for the community to produce the Perl programmers' Python FAQ. We're certainly not the right people to do it, because we're not familiar enough with Perl's oddities. Tom Christiansen had a nice post a few months ago that set out exactly these differences, but he compared Perl to Python 1.4. (Yikes!) It would be a good place to start. Jeremy From jeremy@cnri.reston.va.us Thu Dec 9 17:10:39 1999 From: jeremy@cnri.reston.va.us (jeremy@cnri.reston.va.us) Date: Thu, 9 Dec 1999 12:10:39 -0500 (EST) Subject: [Python-bugs-list] Trap for perl programmers (PR#154) Message-ID: <199912091710.MAA09805@python.org> I think the right approach here is for the community to produce the Perl programmers' Python FAQ. We're certainly not the right people to do it, because we're not familiar enough with Perl's oddities. Tom Christiansen had a nice post a few months ago that set out exactly these differences, but he compared Perl to Python 1.4. (Yikes!) It would be a good place to start. Jeremy From ecn@smart.net Thu Dec 9 19:28:28 1999 From: ecn@smart.net (ecn@smart.net) Date: Thu, 9 Dec 1999 14:28:28 -0500 (EST) Subject: [Python-bugs-list] dyn libs crash w/frozen exectuable (PR#155) Message-ID: <199912091928.OAA12304@python.org> Full_Name: Eric C. Newton Version: Python-1.5.2 OS: AIX 4.2 Submission from: ccgateip.arinc.com (144.243.4.2) Build python on AIX, with shared modules. Use python to freeze a script which uses a shared module (like string manipulation). Run the program (it should crash). Rename the program to "python" and re-run it. It should work fine. In aix_getoldmodules(), this line of code: if (strstr(ldiptr->ldinfo_filename, "python") == NULL) { fails to do the right thing if your program isn't named "python". So symbols for frozen executables are not exported correctly, and the program crashes when the first dynamic library is loaded. Suggested fix: if (strstr(Py_GetProgramName(), ldiptr->ldinfo_filename) == NULL) { This does work for me, but it might not be the right answer. -Eric From piers@cs.su.oz.au Thu Dec 9 22:09:51 1999 From: piers@cs.su.oz.au (piers@cs.su.oz.au) Date: Thu, 9 Dec 1999 17:09:51 -0500 (EST) Subject: [Python-bugs-list] Tkinter winfo_visualsavailable method (PR#156) Message-ID: <199912092209.RAA15220@python.org> Full_Name: Piers Lauder Version: 1.5.2 OS: Solaris/Linux/win95 Submission from: metra.ucc.usyd.edu.au (129.78.64.5) 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}' From doug_wiens@intuit.com Thu Dec 9 23:45:28 1999 From: doug_wiens@intuit.com (doug_wiens@intuit.com) Date: Thu, 9 Dec 1999 18:45:28 -0500 (EST) Subject: [Python-bugs-list] almodule.c (PR#157) Message-ID: <199912092345.SAA16888@python.org> Full_Name: Doug Wiens Version: 1.5.2 OS: Win98 Submission from: fw.intuit.com (216.52.25.3) I was scanning the 1.5.2 source code for an example of the proper usage of the format specifier "O!" for the the function PyArg_ParseTuple(). In .\modules\almodule.c, in function al_Connect() (line 1548), there is the line: if (!PyArg_ParseTuple(args, "ii|O!", &source, &dest, &propobj)) I do believe that "O!" needs 2 C arguments, and "ii|O!" would need 4 C arguments, however, only 3 are specified. I don't know what almodule is, I don't use it, I have not tested to see if this is really a bug or not. Doug Wiens. From guido@CNRI.Reston.VA.US Fri Dec 10 14:23:44 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Fri, 10 Dec 1999 09:23:44 -0500 (EST) Subject: [Python-bugs-list] dyn libs crash w/frozen exectuable (PR#155) Message-ID: <199912101423.JAA03565@python.org> > Build python on AIX, with shared modules. Use python to freeze > a script which uses a shared module (like string manipulation). > Run the program (it should crash). Rename the program to "python" > and re-run it. It should work fine. > > In aix_getoldmodules(), this line of code: > > if (strstr(ldiptr->ldinfo_filename, "python") == NULL) { > > fails to do the right thing if your program isn't named "python". So > symbols for frozen executables are not exported correctly, and the > program crashes when the first dynamic library is loaded. > > Suggested fix: > > if (strstr(Py_GetProgramName(), ldiptr->ldinfo_filename) == NULL) { > > This does work for me, but it might not be the right answer. Thank you. This was already fixed in the CVS archives, see http://www.python.org/download/cvs.html. --Guido van Rossum (home page: http://www.python.org/~guido/) From Vladimir.Marangozov@inrialpes.fr Fri Dec 10 14:23:59 1999 From: Vladimir.Marangozov@inrialpes.fr (Vladimir.Marangozov@inrialpes.fr) Date: Fri, 10 Dec 1999 09:23:59 -0500 (EST) Subject: ecn@smart.net: [Python-bugs-list] dyn libs crash w/frozen exectuable (PR#155) Message-ID: <199912101423.JAA03578@python.org> Guido van Rossum wrote: > > Vladimir, what do you think -- is this the right fix? > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > ------- Forwarded Message > > Date: Thu, 09 Dec 1999 14:28:28 -0500 > From: ecn@smart.net > To: python-bugs-list@python.org > cc: bugs-py@python.org > Subject: [Python-bugs-list] dyn libs crash w/frozen exectuable (PR#155) > > Full_Name: Eric C. Newton > Version: Python-1.5.2 > OS: AIX 4.2 > Submission from: ccgateip.arinc.com (144.243.4.2) > > > Build python on AIX, with shared modules. Use python to freeze > a script which uses a shared module (like string manipulation). > Run the program (it should crash). Rename the program to "python" > and re-run it. It should work fine. > Yes, I've already fixed this and the suggested fix is checked in. cf. the appended message. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 Date: Wed, 4 Aug 1999 14:00:13 -0400 (EDT) To: python-checkins@python.org Subject: [Python-checkins] CVS: python/dist/src/Python importdl.c Sender: python-checkins-admin@python.org Errors-To: python-checkins-admin@python.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Check-in messages from the Python maintainers X-BeenThere: python-checkins@python.org Update of /projects/cvsroot/python/dist/src/Python In directory eric:/projects/python/develop/guido/src/Python Modified Files: importdl.c Log Message: Vladimir Marangozov fixes an AIX-specific problem, writing: """ Following up Robin Dunn's troubles with freeze, here's a patch that fixes an oddity regarding the import logic of shared modules on AIX. Symbol resolution of shared modules is now handled properly for the cases when the python library is linked to a binary with an arbitrary name. This includes the standard python[version] executable, but also applications that are embedding the python core (i.e. linked with libpython[version].a, the latter being static or shared). """ _______________________________________________ Python-checkins mailing list Python-checkins@python.org http://www.python.org/mailman/listinfo/python-checkins From Viagra@weeklysex.com Sat Dec 11 15:21:16 1999 From: Viagra@weeklysex.com (Viagra@weeklysex.com) Date: Sat, 11 Dec 1999 10:21:16 -0500 (EST) Subject: [Python-bugs-list] Natural Viagra Alternative! (Adv.) (PR#158) Message-ID: <199912111521.KAA27941@python.org> The Ultimate Sensation! Get your "Men's Ultra" Now, No Doctor's Prescription needed! 100 % Natural. Feel the Energy, Passion, Desire and the Power rushing back into your Life- Special Sale Price $39.95 - 60 Caplets Includes Shipping & Handling "30 Day Money Back Guarantee" Credit Cards, Money Orders & Checks Accepted Shop by Phone, Toll-Free 24 hours a day at (800) 480-8433 or (954) 969-3928 From piers@cs.su.oz.au Mon Dec 13 02:35:56 1999 From: piers@cs.su.oz.au (piers@cs.su.oz.au) Date: Sun, 12 Dec 1999 21:35:56 -0500 (EST) Subject: [Python-bugs-list] imaplib login password quoting problem (PR#159) Message-ID: <199912130235.VAA13483@python.org> Full_Name: Piers Lauder Version: 1.5.2 OS: Any Submission from: metra.ucc.usyd.edu.au (129.78.64.5) There is a bug in imaplib such that if passwords to the IMAP4 login command contain characters sensitive to the protocol (such as parentheses, or double quotes), the authentication will fail. There is a fix in the latest version of imaplib on my web site at: http://www.cs.su.oz.au/~piers/python/imaplib.py I'd also like to update the documentation to replect this change, could someone please email me the source, and I'll it send back suitably amended. From Leroy.Regis@iupchbio.univ-nantes.fr Mon Dec 13 15:04:13 1999 From: Leroy.Regis@iupchbio.univ-nantes.fr (Leroy.Regis@iupchbio.univ-nantes.fr) Date: Mon, 13 Dec 1999 10:04:13 -0500 (EST) Subject: [Python-bugs-list] Re: A little bug in the ._test of the mailbox module (PR#135) Message-ID: <199912131504.KAA05853@python.org> On 03 12 1999, you wrote : > > I cannot reproduce this problem. > > I don't know what's in the test.py file. Perhaps you are not using the > mailbox module right? > > > This is due to the line 258 of mailbox.py. In this line we've got "msg.fp = > > None" > > (I can't understan why...) > > This line is there because otherwise you would have as many open files > as you inspect messages -- remember that a mailbox can have thousands > of messages and you can't have that many open files. There should be > no need to use the file after reading the headers. > > > Unless you show sample code that elicits this problem I'm going to categorize > this as a use error, because I cannot reproduce it given your information. > > Sorry, > > --Guido van Rossum Excuse me but I don't think this is a user bug! Maybe I haven't said enought the first time. Excuse me for that and please take a look at theses explainations. Here 's the code of my test program (mymbxtest.py): #! /usr/bin/python import mailbox mb = mailbox._test() And here is the way to obtain the bug: [root@banquise]# ./mymbxtest.py Mailbox /var/spool/mail/toto has 0 messages: [root@banquise]# ./mymbxtest.py /var/spool/mail/facteur Mailbox /var/spool/mail/facteur has 7 messages: Mail System Internal 26 Nov 1999 16:26: DON'T DELETE THIS MESSAGE -- F root 1: num = string.atoi(args[1]) print 'Message %d body:'%num msg = msgs[num-1] msg.rewindbody() sys.stdout.write(msg.fp.read()) Here is what I call a bug. Because to use the rfc822 rewindbody() we've got to have a valid Fp, not 'None'. This bug is a little bug for two reasons: - this is only a _test proc, is aim is just to inspire you. - it's a bug in the way we use the rf822 module not the mailbox module. I understand that we can't keep all the fp opened on messages. But if we want to read it with rfc822 we've got to open it before. It's maybe possible to open it jsut before the Msg.rewindbody() and to close it after. Thanks for your response, I'm glad to have your name in my mailbox. --- ||fatal comprehension error - THC00:00 - no-sens - main-reboot ||neurone overflow at 00:00 ____________________________ ____ | _|_|_| _|_|_| _|_|_|_| | {%p# #£)k {8°p}k- _|____|___ | _| _| _| _| leroy@staps.univ-nantes.fr |___|_|_| | _|_|_| _|_| _| _|_|_| objo-admin-system | | | | _| _| _| _| _| leroy@iupchbio.univ-nantes.fr _|_|__\ | _| _|_|_|_|_|_|_|_|_| |_______________________________||___| From fdrake@acm.org Mon Dec 13 18:21:06 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 13 Dec 1999 13:21:06 -0500 (EST) Subject: [Python-bugs-list] imaplib login password quoting problem (PR#159) In-Reply-To: <199912130235.VAA13483@python.org> References: <199912130235.VAA13483@python.org> Message-ID: <14421.14610.530178.49451@weyr.cnri.reston.va.us> piers@cs.su.oz.au writes: > I'd also like to update the documentation to replect this change, could > someone please email me the source, and I'll it send back suitably amended. (For the bug database record.) I've sent Piers the current documentation sources in a separate message (to avoid polluting the bug system with attachments). -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Mon Dec 13 18:20:32 1999 From: fdrake@acm.org (fdrake@acm.org) Date: Mon, 13 Dec 1999 13:20:32 -0500 (EST) Subject: [Python-bugs-list] imaplib login password quoting problem (PR#159) Message-ID: <199912131820.NAA09690@python.org> piers@cs.su.oz.au writes: > I'd also like to update the documentation to replect this change, could > someone please email me the source, and I'll it send back suitably amended. (For the bug database record.) I've sent Piers the current documentation sources in a separate message (to avoid polluting the bug system with attachments). -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From gpk@bell-labs.com Tue Dec 14 15:02:56 1999 From: gpk@bell-labs.com (gpk@bell-labs.com) Date: Tue, 14 Dec 1999 10:02:56 -0500 (EST) Subject: [Python-bugs-list] Ranlib is obsolete - more a FYI than a bug (PR#160) Message-ID: <199912141502.KAA08249@python.org> Full_Name: Greg Kochanski Version: 1.5.2 OS: Solaris 2.6 Submission from: h-135-104-33-130.research.bell-labs.com (135.104.33.130) make install in the python distribution on Solaris 2.6 will terminate if ranlib is not in the search path. Ranlib is obsolete in solaris 2.x, and is not needed, the functionality being pulled into ar(1). I saw this problem when installing as a different user than the one I compiled as, so it's probably not important if your search path doesn't change. Man mage follows: man ranlib User Commands ranlib(1) NAME ranlib - convert archives to random libraries SYNOPSIS /usr/ccs/bin/ranlib archive DESCRIPTION ranlib was used in SunOS 4.x to add a table of contents to archive libraries, which converted each archive to a form that could be linked more rapidly. This is no longer needed as the ar(1) command automatically provides all the func- tionality ranlib used to provide. This script is provided as a convenience for software developers who need to maintain Makefiles that are portable across a variety of operating systems. EXIT STATUS ranlib has exit status 0. ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: __________________________________ | ATTRIBUTE TYPE| ATTRIBUTE VALUE| |__________________________________ | Availability | SUNWbtool | |_______________|_________________| SEE ALSO ar(1), ar(4), attributes(5) SunOS 5.6 Last change: 13 Apr 1995 1 From guido@CNRI.Reston.VA.US Tue Dec 14 22:19:06 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 14 Dec 1999 17:19:06 -0500 (EST) Subject: [Python-bugs-list] Re: A little bug in the ._test of the mailbox module (PR#135) Message-ID: <199912142219.RAA18143@python.org> > Excuse me but I don't think this is a user bug! > Maybe I haven't said enought the first time. > Excuse me for that and please take a look at theses explainations. You're right. I asked the author of the module but it turns out that I added that little assignment to the test function myself, thereby accidentally breaking the test case with an extra argument. Here's a fix, also in the CVS tree now: Index: mailbox.py =================================================================== RCS file: /projects/cvsroot/python/dist/src/Lib/mailbox.py,v retrieving revision 1.16 retrieving revision 1.17 diff -c -r1.16 -r1.17 *** mailbox.py 1999/03/24 16:20:45 1.16 --- mailbox.py 1999/12/14 22:18:37 1.17 *************** *** 255,261 **** if msg is None: break msgs.append(msg) ! msg.fp = None if len(args) > 1: num = string.atoi(args[1]) print 'Message %d body:'%num --- 255,262 ---- if msg is None: break msgs.append(msg) ! if len(args) <= 1: ! msg.fp = None if len(args) > 1: num = string.atoi(args[1]) print 'Message %d body:'%num --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Dec 16 20:48:47 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 16 Dec 1999 15:48:47 -0500 (EST) Subject: [Python-bugs-list] Tkinter inconsistency (missing methods) (PR#161) Message-ID: <199912162048.PAA05611@python.org> ------- 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 From dwr2@ix.netcom.com Sun Dec 19 13:38:24 1999 From: dwr2@ix.netcom.com (dwr2@ix.netcom.com) Date: Sun, 19 Dec 1999 08:38:24 -0500 (EST) Subject: [Python-bugs-list] ntpath.expandvars doesn't handle case properly (PR#162) Message-ID: <199912191338.IAA02933@python.org> Full_Name: Donald Wallace Rouse II Version: 1.5 OS: Windows 95 Submission from: roc-ny6-102.ix.netcom.com (198.211.253.102) 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 From usayhello@earthlink.net Mon Dec 20 05:41:57 1999 From: usayhello@earthlink.net (usayhello@earthlink.net) Date: Mon, 20 Dec 1999 00:41:57 -0500 (EST) Subject: [Python-bugs-list] Save 50-80% on International Calls and Win $500 in Free phone calls!!!!! (PR#163) Message-ID: <199912200541.AAA20218@python.org> Save up to 80% on your INTERNATIONAL long distance phone bill. Join our easy-to-use callback service today for FREE. There are no monthly minimums, surcharges or set-up fees, just low flat rates 24 hours, everyday. Visit our website: www.sayhello.cc and win $500 in FREE phone calls. HELLO MIDDLE EAST http://www.sayhello.cc Email: usayhello@earthlink.net Sample our LOW rate chart below. To get cost of calls just add cost of the country you are calling FROM to cost of the country you are calling TO. Complete rate list available on our website. Prices are per minute in USD. Algeria 0.31 Australia 0.08 Austria 0.12 Azerbaijan 0.42 Bahamas 0.18 Bahrain 0.41 Bangladesh 0.60 Bangladesh Dhaka 0.49 Belgium 0.08 Brazil 0.28 Canada 0.06 Chile 0.15 China 0.32 Columbia 0.25 Cyprus 0.28 Czechoslovakia 0.28 Denmark 0.08 Djibouti 0.69 Dominican Rep. 0.17 Egypt 0.59 Ethiopia 0.95 Finland 0.11 France 0.07 Georgia 0.46 Germany 0.06 Greece 0.25 Hong Kong 0.07 Hungary 0.23 India 0.69 India New Delhi 0.66 India-Bomba 0.54 India-Madras 0.62 India-Bangalore 0.54 Indonesia 0.35 Iran 0.58 Iraq 0.68 Ireland 0.09 Israel 0.13 Italy 0.11 Japan 0.09 Japan-Tokyo 0.08 Jordan 0.43 Kazakhstan 0.49 Kenya 0.60 Kuwait 0.54 Kyrgyzstan 0.57 Lebanon 0.38 Liberia 0.43 Libya 0.32 Malaysia 0.22 Malta 0.17 Mauritania 0.66 Mexico 0.15 Morocco 0.42 Nepal 0.83 Netherlands 0.07 New Zealand 0.09 Nigeria 0.69 Norway 0.11 Oman 0.47 Pakistan 0.58 Pakistan\Karachi 0.56 Philippines 0.26 Poland 0.25 Qatar 0.46 Romania 0.37 Russia 0.31 Russia-Moscow 0.12 Russia-St.Petersberg 0.22 Saudi Arabia 0.62 Singapore Rep. 0.15 Somalia 0.68 South Africa 0.34 South Korea 0.12 Spain 0.11 Sri Lanka 0.74 Sudan 0.43 Sweden 0.05 Switzerland 0.09 Syria 0.51 Taiwan 0.14 Tajikistan 0.46 Tanzania 0.42 Thailand 0.35 Thailand bangkok 0.29 Tunisia 0.42 Turkey 0.31 Turkmenistan 0.54 Ukraine 0.29 United Arab Emirates 0.30 United Kingdom 0.05 USA 0.05 Yemen 0.63 HELLO MIDDLE EAST Hello Corp Hello Building 434 Sunrise Highway West Islip N.Y. 11795 Tel: 516-321-1204 Fax: 516-321-1758 Email: usayhello@earthlink.net http://www.sayhello.cc From python-bugreport@derf.net Tue Dec 21 13:27:28 1999 From: python-bugreport@derf.net (python-bugreport@derf.net) Date: Tue, 21 Dec 1999 08:27:28 -0500 (EST) Subject: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164) Message-ID: <199912211327.IAA05930@python.org> Full_Name: Neil "Fred" Picciotto Version: 1.5.2 OS: RedHat 5.2; Linux 2.2.12 Submission from: (NULL) (198.144.205.108) time.strptime() seems to fail when the time zone ('%Z') appears in the format string. when it is omitted from the format string (and from the string being parsed), strptime() works fine. here is a sample script which demonstrates the bug: ------ #!/usr/bin/python import time timetuple0 = time.localtime(time.time()) print timetuple0 format1 = '%a %b %d %H:%M:%S %Y' timestring1 = time.strftime( format1 , timetuple0 ) print timestring1 timetuple1 = time.strptime( timestring1 , format1 ) print timetuple1 format2 = '%a %b %d %H:%M:%S %Z %Y' timestring2 = time.strftime( format2 , timetuple0 ) print timestring2 timetuple2 = time.strptime( timestring2 , format2 ) print timetuple2 ------ when i run the above, i get the following output: ------ (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 1999 (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 PST 1999 Traceback (innermost last): File "./test.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch ------ From guido@CNRI.Reston.VA.US Tue Dec 21 14:11:33 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 21 Dec 1999 09:11:33 -0500 (EST) Subject: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164) Message-ID: <199912211411.JAA07132@python.org> > time.strptime() seems to fail when the time zone ('%Z') appears in > the format string. when it is omitted from the format string (and > from the string being parsed), strptime() works fine. Reporting this as a Python bug is not going to fix it. The time.strptime() function in Python is a very thin wrapper around the strptime() function in the C library. We get a lot of complaints about this, but there's no way that we're able to fix this -- it's the C strptime() function that needs to be fixed. Write to your friendly Linux support people! --Guido van Rossum (home page: http://www.python.org/~guido/) From xxx-bad@juno.com Tue Dec 21 16:43:09 1999 From: xxx-bad@juno.com (xxx-bad@juno.com) Date: Tue, 21 Dec 1999 11:43:09 -0500 (EST) Subject: [Python-bugs-list] redirected stdout under Windows NT (PR#165) Message-ID: <199912211643.LAA09922@python.org> 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 From guido@CNRI.Reston.VA.US Tue Dec 21 16:46:34 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Tue, 21 Dec 1999 11:46:34 -0500 (EST) Subject: [Python-bugs-list] redirected stdout under Windows NT (PR#165) Message-ID: <199912211646.LAA10030@python.org> > 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/) From guido@CNRI.Reston.VA.US Tue Dec 21 16:47:12 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Tue, 21 Dec 1999 11:47:12 -0500 Subject: [Python-bugs-list] redirected stdout under Windows NT (PR#165) In-Reply-To: Your message of "Tue, 21 Dec 1999 11:43:09 EST." <199912211643.LAA09922@python.org> References: <199912211643.LAA09922@python.org> Message-ID: <199912211647.LAA12601@eric.cnri.reston.va.us> > 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/) From mhammond@skippinet.com.au Tue Dec 21 22:54:22 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 22 Dec 1999 09:54:22 +1100 Subject: [Python-bugs-list] redirected stdout under Windows NT (PR#165) In-Reply-To: <199912211643.LAA09922@python.org> Message-ID: 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 > From mhammond@skippinet.com.au Tue Dec 21 22:54:48 1999 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Tue, 21 Dec 1999 17:54:48 -0500 (EST) Subject: [Python-bugs-list] redirected stdout under Windows NT (PR#165) Message-ID: <199912212254.RAA16419@python.org> 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 > From aa8vb@ipass.net Wed Dec 22 12:58:00 1999 From: aa8vb@ipass.net (aa8vb@ipass.net) Date: Wed, 22 Dec 1999 07:58:00 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <199912221258.HAA09793@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: Irix Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) 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 From guido@CNRI.Reston.VA.US Wed Dec 22 14:29:41 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 22 Dec 1999 09:29:41 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <199912221429.JAA12755@python.org> > 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/) From fdrake@acm.org Wed Dec 22 15:43:32 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Wed, 22 Dec 1999 10:43:32 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) In-Reply-To: <199912221429.JAA12755@python.org> References: <199912221429.JAA12755@python.org> Message-ID: <14432.61860.308331.746849@weyr.cnri.reston.va.us> 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 From fdrake@acm.org Wed Dec 22 15:42:50 1999 From: fdrake@acm.org (fdrake@acm.org) Date: Wed, 22 Dec 1999 10:42:50 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <199912221542.KAA13934@python.org> 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 From guido@CNRI.Reston.VA.US Wed Dec 22 16:45:34 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 22 Dec 1999 11:45:34 -0500 Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) In-Reply-To: Your message of "Wed, 22 Dec 1999 10:43:32 EST." <14432.61860.308331.746849@weyr.cnri.reston.va.us> References: <199912221429.JAA12755@python.org> <14432.61860.308331.746849@weyr.cnri.reston.va.us> Message-ID: <199912221645.LAA16325@eric.cnri.reston.va.us> > 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/) From guido@CNRI.Reston.VA.US Wed Dec 22 16:45:01 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 22 Dec 1999 11:45:01 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <199912221645.LAA14803@python.org> > 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/) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Dec 22 16:59:07 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 22 Dec 1999 11:59:07 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) References: <199912221542.KAA13934@python.org> Message-ID: <14433.859.966597.180380@anthem.cnri.reston.va.us> >>>>> "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 From bwarsaw@cnri.reston.va.us Wed Dec 22 16:58:26 1999 From: bwarsaw@cnri.reston.va.us (bwarsaw@cnri.reston.va.us) Date: Wed, 22 Dec 1999 11:58:26 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <199912221658.LAA15062@python.org> >>>>> "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 From daniel@dittmar.net Wed Dec 29 14:56:27 1999 From: daniel@dittmar.net (daniel@dittmar.net) Date: Wed, 29 Dec 1999 09:56:27 -0500 (EST) Subject: [Python-bugs-list] ConfigParser: Interpolation does not work (PR#167) Message-ID: <199912291456.JAA03185@python.org> Full_Name: Daniel Dittmar Version: 1.5.2 OS: NT Submission from: proxy40.sap-ag.de (194.39.131.36) method ConfigParser::get while depth < 10: # Loop through this until it's done depth = depth + 1 if not string.find(value, "%("): try: test should read string.find(value, "%(") != -1 From aa8vb@ipass.net Fri Dec 31 00:17:22 1999 From: aa8vb@ipass.net (aa8vb@ipass.net) Date: Thu, 30 Dec 1999 19:17:22 -0500 (EST) Subject: [Python-bugs-list] REQ: array module should provide "swap to native byte order" functionality, similar to struct module (PR#166) Message-ID: <199912310017.TAA10332@python.org> 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