From guido@CNRI.Reston.VA.US Mon Nov 1 22:56:39 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 1 Nov 1999 17:56:39 -0500 (EST) Subject: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Message-ID: <199911012256.RAA22665@python.org> > When python is compiled with thread support and readline, ^C no longer > works properly (interpreter goes into an infinite loop). > (Tried with readline 2.0, 2.2 and 4.0). Thanks for your bug report. I see that you are using FreeBSD. Could it be a FreeBSD related problem? I don't see the same thing on Solaris or Red Hat Linux. Also, can you describe exactly how you reproduce the problem? --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Wed Nov 3 15:42:30 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 3 Nov 1999 10:42:30 -0500 (EST) Subject: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Message-ID: <199911031542.KAA17845@python.org> ------- Forwarded Message Date: Tue, 02 Nov 1999 11:57:23 +0000 From: Alex Zbyslaw To: guido@cnri.reston.va.us Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline >> When python is compiled with thread support and readline, ^C no longer >> works properly (interpreter goes into an infinite loop). >> (Tried with readline 2.0, 2.2 and 4.0). >Thanks for your bug report. I see that you are using FreeBSD. Could >it be a FreeBSD related problem? I don't see the same thing on >Solaris or Red Hat Linux. > >Also, can you describe exactly how you reproduce the problem? > >--Guido van Rossum (home page: http://www.python.org/~guido/) Thanks for your mail, Guido. Yes, I suppose it could be a FreeBSD problem, though I was originally put on to the readline connection by some articles in comp.lang.python which mentioned extremely similar symptoms under Debian Linux. What those articles did not mention was the thread connection which I guessed for myself. See articles titled "Control-C on Unix meisbehaviour?" on 18th Oct 1999. People in that thread reported similar problems on various systems, whilst others had no problem on apparently identical systems. No one mentioned if they had thread support. Creating the problem is, for me, simple. I compile python 1.5.2 with thread support enabled. (Thread and signal tests are passed by make test and a quickie thread program works as expected). If I go into the interpreter python and type ^C, everything goes into an infinite loop. If I recompile python without threads, but with readline, then go into the interpreter then press ^C I get KeyboardInterrupt as expected. If I recompile with threads but without readline, then again, I get KeyboardInterrupt as expected. In all three cases, pressing ^C while a program is running gets correct behaviour. >From what I can determine: The readline module was written so that it bypassed any signal handler installed by the readline library. It institutes its own handler in readline.c (onintr) which catches the interrupt and returns NULL (which somewhere back down the line is interpreted as KeyboardInterrupt). However, with threads enabled (but no readline) there seems to be a different behaviour, where the interrupt is caught by the regular signal handler (I forget the name but its in my bug report - in signalmodule.c). My guess was that with threads enabled this signal handler was doing something important. But with readline support turned on, this handler was not being called which caused some problem occur. I did try adapting the code in readline.c to call this signal handler itself, but that didn't seem to work (though I forget what happened). What my patch does is to forget about the local signal handler 'onintr' and, instead, stick with whatever the "default" signal handler is. readline_4.0 allows you to turn off any signal handling in the readline library itself, so the "default" handler will be whatever python installs (in signalmodule.c). This then "works" in that pressing ^C does not generate an infinite loop. But the call_readline function in readline.c does not immediately return NULL, so you have to press RETURN before the KeyboardInterrupt is generated. I never did figure out a way to both call the default signal handler and return a NULL from call_readline -- which I believe would cause "correct" ^C behaviour. My C is somewhat rusty as I spend my time in Python (by choice) and Perl (by neccessity). I'm not sure what else I can tell you about the problem, but if there is any more data I could provide for you, please ask. As another bizarre data point: when I run a threaded python interpreter on a program which does not use threads, and pipe the output to less, less gets very confused and fails to update about half the screen, leaving it blank. This happens after hitting SPACE a couple of times. All the data is there, and if I jump less to the end of input and then go back through the the data, I can see it all normally. Same program and unthreaded python and less works just fine. If you have ANY idea why adding thread support could affect a program further down a pipe I'd love to know. By the way, I have no objection to making my bug report and patch public, as long as there is some way to remove my email address from it. I have had only one piece of spam in the last year and I'd like to keep it that way :-) As the good cafe owner said "Spam's orf"! Although it's not perfect, the patch has made threaded python usable for me. If there are other people out there in the same boat and it helped them, that would be great. - -- Phone: 0131 468 2422 Email: xfb52@dial.pipex.com ------- End of Forwarded Message From bkc@murkworks.com Thu Nov 4 00:27:17 1999 From: bkc@murkworks.com (bkc@murkworks.com) Date: Wed, 3 Nov 1999 19:27:17 -0500 (EST) Subject: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121) Message-ID: <199911040027.TAA11327@python.org> I tried to post a bug, but got this error: The system encountered a fatal error After command: Received: The last error code was: Connection refused Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug  {HYPERLINK "../python-bugs/"}Public interface  {HYPERLINK "../python-bugs.private"}Private interface (requires password)  {HYPERLINK "http://www.python.org/"}Python home page ----- Here's what I said for Python 1.5.2 on Win32 #0 PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not usable on WIN32 from non-VC applications because python15.dll is statically linked to the MS runtime DLL. Embedding applications that try to use these functions are passing in FILE * structures that do not match MS's runtime format. For example, I'm using Python in a Borland C++ Builder application. Although I can open a FILE *, when passed to python15.dll the FILE * is not usable. The addition of two helper functions would solve this problem: FILE * PyRun_OpenFile(char *file, char *mode) { return fopen(file,mode) } int PyRun_CloseFile(FILE *ptr) { return fclose(ptr) } This way embedding apps could get python15.dll to open the file and it would work. A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From jack@oratrix.nl Wed Nov 3 22:32:19 1999 From: jack@oratrix.nl (Jack Jansen) Date: Wed, 03 Nov 1999 23:32:19 +0100 Subject: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) In-Reply-To: Message by guido@CNRI.Reston.VA.US , Wed, 3 Nov 1999 10:42:30 -0500 (EST) , <199911031542.KAA17845@python.org> Message-ID: <19991103223224.6AB06EA119@oratrix.oratrix.nl> > As another bizarre data point: when I run a threaded python interpreter > on a program which does not use threads, and pipe the output to less, > less gets very confused and fails to update about half the screen, > leaving it blank. This happens after hitting SPACE a couple of times. > All the data is there, and if I jump less to the end of input and then > go back through the the data, I can see it all normally. Same program > and unthreaded python and less works just fine. If you have ANY idea > why adding thread support could affect a program further down a pipe I'd > love to know. As I like puzzles I spent some time thinking on this, and it must be either (a) kernel bug, (b) a very strange stdio bug or (c) an incorrect observation. If your system supports memory-mapped I/O and stdio uses it and it can somehow signal that a whole buffer is available while it isn't but only the tail end is available (because it uses an overlapping memcopy which goes back-to-front, for instance) the reader in the pipe might wakeup too early and see null bytes. But if this was a bet I think I'd put my money on (c) (but absolutely no offense meant!). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jack@oratrix.nl Thu Nov 4 00:32:25 1999 From: jack@oratrix.nl (jack@oratrix.nl) Date: Wed, 3 Nov 1999 19:32:25 -0500 (EST) Subject: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Message-ID: <199911040032.TAA11700@python.org> > As another bizarre data point: when I run a threaded python interpreter > on a program which does not use threads, and pipe the output to less, > less gets very confused and fails to update about half the screen, > leaving it blank. This happens after hitting SPACE a couple of times. > All the data is there, and if I jump less to the end of input and then > go back through the the data, I can see it all normally. Same program > and unthreaded python and less works just fine. If you have ANY idea > why adding thread support could affect a program further down a pipe I'd > love to know. As I like puzzles I spent some time thinking on this, and it must be either (a) kernel bug, (b) a very strange stdio bug or (c) an incorrect observation. If your system supports memory-mapped I/O and stdio uses it and it can somehow signal that a whole buffer is available while it isn't but only the tail end is available (because it uses an overlapping memcopy which goes back-to-front, for instance) the reader in the pipe might wakeup too early and see null bytes. But if this was a bet I think I'd put my money on (c) (but absolutely no offense meant!). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From guido@CNRI.Reston.VA.US Thu Nov 4 01:08:11 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 03 Nov 1999 20:08:11 -0500 Subject: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121) In-Reply-To: Your message of "Wed, 03 Nov 1999 19:27:17 EST." <199911040027.TAA11327@python.org> References: <199911040027.TAA11327@python.org> Message-ID: <199911040108.UAA11544@eric.cnri.reston.va.us> > I tried to post a bug, but got this error: > > The system encountered a fatal error We were being slammed by a defective spider (or, if you're more paranoid, by a hacker) so we temporarily turned off the webserver. It should be back on now. > Here's what I said for Python 1.5.2 on Win32 #0 > > PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not > usable on WIN32 from non-VC applications because python15.dll is statically > linked to the MS runtime DLL. Embedding applications that try to use these > functions are passing in FILE * structures that do not match MS's runtime > format. > > For example, I'm using Python in a Borland C++ Builder application. Although I > can open a FILE *, when passed to python15.dll the FILE * is not usable. > > The addition of two helper functions would solve this problem: > > FILE * PyRun_OpenFile(char *file, char *mode) > { > return fopen(file,mode) > } > > int PyRun_CloseFile(FILE *ptr) > { > return fclose(ptr) > } > > This way embedding apps could get python15.dll to open the file and it would > work. > > A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. This is an elegant solution. I think I'll add it. Could you mail me your suggestion again with the legal boilerplate included? See http://www.python.org/1.5/bugrelease.html for the text and explanation. Our lawyers require that I request this silliness... --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Nov 4 01:09:22 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Wed, 3 Nov 1999 20:09:22 -0500 (EST) Subject: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121) Message-ID: <199911040109.UAA12897@python.org> > I tried to post a bug, but got this error: > > The system encountered a fatal error We were being slammed by a defective spider (or, if you're more paranoid, by a hacker) so we temporarily turned off the webserver. It should be back on now. > Here's what I said for Python 1.5.2 on Win32 #0 > > PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not > usable on WIN32 from non-VC applications because python15.dll is statically > linked to the MS runtime DLL. Embedding applications that try to use these > functions are passing in FILE * structures that do not match MS's runtime > format. > > For example, I'm using Python in a Borland C++ Builder application. Although I > can open a FILE *, when passed to python15.dll the FILE * is not usable. > > The addition of two helper functions would solve this problem: > > FILE * PyRun_OpenFile(char *file, char *mode) > { > return fopen(file,mode) > } > > int PyRun_CloseFile(FILE *ptr) > { > return fclose(ptr) > } > > This way embedding apps could get python15.dll to open the file and it would > work. > > A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. This is an elegant solution. I think I'll add it. Could you mail me your suggestion again with the legal boilerplate included? See http://www.python.org/1.5/bugrelease.html for the text and explanation. Our lawyers require that I request this silliness... --Guido van Rossum (home page: http://www.python.org/~guido/) From bkc@murkworks.com Thu Nov 4 01:24:11 1999 From: bkc@murkworks.com (bkc@murkworks.com) Date: Wed, 3 Nov 1999 20:24:11 -0500 (EST) Subject: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121) Message-ID: <199911040124.UAA13435@python.org> Here it is again. Also, I believe this will resolve FAQ entry 8.10 > 8.10. Can't get Py_RunSimpleFile() to work. > This is very sensitive to the compiler vendor, version and (perhaps) even > options. If the FILE* structure in your embedding program isn't the same as > is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs > (python15.dll) are all compiled with MS VC++ 5.0 and with > multithreading-DLL options (/MD, I think). > > If you can't change compilers or flags, try using Py_RunSimpleString(). A > trick to get it to run an arbitrary file is to construct a call to > execfile() with the name of your file as argument. > > > > --------------------------------------------------------------------------- > ----- > Here's what I said for Python 1.5.2 on Win32 #0 > > PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not > usable on WIN32 from non-VC applications because python15.dll is statically > linked to the MS runtime DLL. Embedding applications that try to use these > functions are passing in FILE * structures that do not match MS's runtime > format. > > For example, I'm using Python in a Borland C++ Builder application. Although I > can open a FILE *, when passed to python15.dll the FILE * is not usable. > > The addition of two helper functions would solve this problem: > > FILE * PyRun_OpenFile(char *file, char *mode) > { > return fopen(file,mode) > } > > int PyRun_CloseFile(FILE *ptr) > { > return fclose(ptr) > } > > This way embedding apps could get python15.dll to open the file and it would > work. > > A temporary workaround is to always load the .pyc file in PyRun_SimpleFile.. 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. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From ygyang@hotmail.com Fri Nov 5 14:15:16 1999 From: ygyang@hotmail.com (ygyang@hotmail.com) Date: Fri, 5 Nov 1999 09:15:16 -0500 (EST) Subject: [Python-bugs-list] Python on Windows can (PR#122) Message-ID: <199911051415.JAA24859@python.org> Full_Name: Version: OS: Submission from: (NULL) (203.127.51.229) Hi, Don't know if this is considered a bug: Python.exe crashed when I tried to use a recursive function, like the infamous factorial. I've downloaded and tried this on both Python 1.5.1 and 1.5.2 of the Windows 95/98/NT version. The function is as follows def fact(n): if n==1: return 1 else: return n*fact(n) fact(1) returned 1 with no problems. But fact(2) or any argument greater than 1 crashed python with a Windows application error window popping up. I've run this before on a Linux version of Python without any problems. From ygyang@hotmail.com Fri Nov 5 14:16:35 1999 From: ygyang@hotmail.com (ygyang@hotmail.com) Date: Fri, 5 Nov 1999 09:16:35 -0500 (EST) Subject: [Python-bugs-list] Recursive Functions on Python on Windows (PR#123) Message-ID: <199911051416.JAA24937@python.org> Full_Name: Yang, Yingguo Version: 1.5.1 and 1.5.2 (Windows 95/98/NT) OS: Windows NT Svr/Workstation Submission from: (NULL) (203.127.51.229) Hi, Don't know if this is considered a bug: Python.exe crashed when I tried to use a recursive function, like the infamous factorial. I've downloaded and tried this on both Python 1.5.1 and 1.5.2 of the Windows 95/98/NT version. The function is as follows def fact(n): if n==1: return 1 else: return n*fact(n) fact(1) returned 1 with no problems. But fact(2) or any argument greater than 1 crashed python with a Windows application error window popping up. I've run this before on a Linux version of Python without any problems. From n89553@squid.upb.de Fri Nov 5 15:01:35 1999 From: n89553@squid.upb.de (n89553@squid.upb.de) Date: Fri, 5 Nov 1999 10:01:35 -0500 (EST) Subject: [Python-bugs-list] magic key of bsddb (PR#124) Message-ID: <199911051501.KAA26609@python.org> Full_Name: Mirko Liss Version: 1.5.2 OS: suse linux 6.2 (x86) Submission from: brassmonkey.uni-paderborn.de (131.234.134.84) suse linux 6.2 comes with a flavour of bsddb that uses a magic key of 0 (zero). So you cannot open files you created using the module dbhash via anydbm. This affects shelve as well. You can fix it by editing /usr/lib/python/whichdb.py : # Check for BSD hash # patch for suse 6.2 , mirko liss # if magic in (0x00061561, 0x61150600): if magic in (0x00061561, 0x61150600, 0): return "dbhash" From guido@CNRI.Reston.VA.US Fri Nov 5 15:02:54 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Fri, 5 Nov 1999 10:02:54 -0500 (EST) Subject: [Python-bugs-list] Recursive Functions on Python on Windows (PR#123) Message-ID: <199911051502.KAA26719@python.org> > Don't know if this is considered a bug: > Python.exe crashed when I tried to use a recursive function, > like the infamous factorial. > I've downloaded and tried this on both Python 1.5.1 and 1.5.2 > of the Windows 95/98/NT version. > > The function is as follows > > def fact(n): > if n==1: return 1 > else: return n*fact(n) > > fact(1) returned 1 with no problems. > But fact(2) or any argument greater than 1 crashed python > with a Windows application error window popping up. > > I've run this before on a Linux version of Python without any problems. Do you realize that your code has a bug? It recurses infinitely because you are calling fact(n) instead of fact(n-1). On Linux, you would have gotten a stack overflow error. Unfortunately, the stack overflow code on Windows is broken (the limit on recursion is too high, so it runs out of stack memory causing a crash before the recursion limit is triggered). Christian Tismer has posted a patch for the binary (python15.dll) which solves this. It has also of course been fixed in our source code. --Guido van Rossum (home page: http://www.python.org/~guido/) From ygyang@hotmail.com Sat Nov 6 08:54:11 1999 From: ygyang@hotmail.com (ygyang@hotmail.com) Date: Sat, 6 Nov 1999 03:54:11 -0500 (EST) Subject: [Python-bugs-list] Recursive Functions on Python on Windows (PR#123) Message-ID: <199911060854.DAA26009@python.org> Hi Guido, Oops! Thanks for pointing out the bug. You're right (should be fact(n-1) which runs fine). ----Original Message Follows---- From: Guido van Rossum To: ygyang@hotmail.com CC: bugs-py@python.org Subject: Re: [Python-bugs-list] Recursive Functions on Python on Windows (PR#123) Date: Fri, 05 Nov 1999 10:02:53 -0500 From guido@CNRI.Reston.VA.US Mon Nov 8 15:30:21 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 8 Nov 1999 10:30:21 -0500 (EST) Subject: Alex Zbyslaw: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline (PR#120) Message-ID: <199911081530.KAA09116@python.org> ------- Forwarded Message Date: Sat, 06 Nov 1999 11:17:00 +0000 From: Alex Zbyslaw To: guido@cnri.reston.va.us Subject: RE: Re: [Python-bugs-list] PRIVATE: Threads and readline This is the message I posted today on comp.lang.python. Btw, I forgot to mention that to compile for thread support on FreeBSD 3.2 (and I would think 3.3) you only need to specify "-pthread" on the link line. That automatically links in the threaded C libraries. Everything else from the standard configure would appear to be correct. All the best, - --Alex Subject: Re: Control-C on Unix misbehaviour? Date: Sat, 06 Nov 1999 11:08:05 +0000 Quinn Dunkan wrote: > > On Mon, 18 Oct 1999 15:47:52 +0200, flight@mathi.uni-heidelberg.de > Here's a data point for Irix6: > If you hit ^C at the >>> prompt with readline loaded (python 1.5), python > stops responding. Further ^Cs do nothing, in fact the only way I've found > to get out is to kill from another shell or hit ^z kill %. I had exactly the same problem on FreeBSD 3.2 but ONLY when I had thread support enabled. I have eventually tracked the problem down to a bad interaction (read library/kernel bug) between threads/sigjmp and interrupted reads. I have created two "fixes" which can be applied either to a) python or b) python and readline which fix the problems differently. The fixes are pretty trivial and so far they work for me. You can check them out at http://www.xfb52.dial.pipex.com/patches/python.shtml I don't know how they may affect people who have had ^C dumping them into a shell. No one else has mentioned whether they had thread support enabled or not. >From extensive poking around I am quite sure that this misbehaviour is not a bug in either Python or readline. Good luck, - --Alex ------- End of Forwarded Message From kauer@pheno.physics.wisc.edu Wed Nov 10 00:55:21 1999 From: kauer@pheno.physics.wisc.edu (kauer@pheno.physics.wisc.edu) Date: Tue, 9 Nov 1999 19:55:21 -0500 (EST) Subject: [Python-bugs-list] expert on extension modules and multiple interpreters? (PR#125) Message-ID: <199911100055.TAA03754@python.org> 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." From m.boorman@ieee.org Wed Nov 10 01:10:04 1999 From: m.boorman@ieee.org (m.boorman@ieee.org) Date: Tue, 9 Nov 1999 20:10:04 -0500 (EST) Subject: [Python-bugs-list] win32service.OpenService does not handle embeded spaces. (PR#126) Message-ID: <199911100110.UAA03974@python.org> Full_Name: Mathew Boorman Version: 1.5.2 OS: NT 4.0 Submission from: pan.admiral.co.uk (193.112.216.1) win32service.OpenService does not handle embeded spaces in the service name, it does not find the name. The following code sample works OK for the first names, but any Service Names with embedded spaces fail, with a message as follows. Note that this occurs with both Win32all v125 and 127(beta3). (The output supplied is using 127) Starting the service from the NT command line works fine with command: net start "Protected Storage" MSDTC MSSQLServer Protected Storage Traceback (innermost last): File "d:\Program Files\Python\Pythonwin\pywin\framework\scriptutils.py", line 313, in RunScript exec codeObject in __main__.__dict__ File "D:\Projects\python\startService.py", line 34, in ? win32serviceutil.RestartService(b) File "d:\Program Files\Python\win32\lib\win32serviceutil.py", line 319, in RestartService raise win32service.error, (hr, name, msg) api_error: (1060, 'OpenService', 'The specified service does not exist as an installed service.') Code fragment: import win32serviceutil, pywintypes import win32service, win32api, win32con, winerror a = [ "MSDTC", "MSSQLServer", "Protected Storage", "World Wide Web Publishing Service", "FTP Publishing Service"] for x in a: print x win32serviceutil.RestartService(x) From mhammond@skippinet.com.au Wed Nov 10 03:48:31 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Wed, 10 Nov 1999 14:48:31 +1100 Subject: m.boorman@ieee.org: [Python-bugs-list] win32service.OpenService does not handle embeded sp aces. (PR#126) In-Reply-To: <199911100338.WAA22752@eric.cnri.reston.va.us> Message-ID: <002b01bf2b2e$753cebc0$0501a8c0@bobcat> > Full_Name: Mathew Boorman > Version: 1.5.2 > OS: NT 4.0 > Submission from: pan.admiral.co.uk (193.112.216.1) > > > win32service.OpenService does not handle embeded spaces in > the service name, it > does not find the name. The following code sample works OK > for the first names, > but any Service Names with embedded spaces fail, with a > message as follows. This is not a bug. You are confusing the service name with the "service display name". Service names can not have spaces in them. eg: > Protected Storage This is the display name. The service name is "ProtectedStorage". The "net start" command may well handle this. However, the Python extensions do not. I do not class this as a bug, but a reasonable feature request that I may add sometime - if you feel this is important, feel free to submit a patch for this (directly to me, rather than the bugs list) Thanks, Mark. From a.amoroso@alcatel.de Thu Nov 11 09:03:54 1999 From: a.amoroso@alcatel.de (a.amoroso@alcatel.de) Date: Thu, 11 Nov 1999 04:03:54 -0500 (EST) Subject: [Python-bugs-list] fnmatch.fnmatch (PR#127) Message-ID: <199911110903.EAA09987@python.org> Full_Name: Dr. Andreas Amoroso Version: 1.5.2 OS: Solaris Submission from: slspu2.alcatel.de (194.113.59.80) The function fnmatch.fnmatch() is not case-insensitive as described in the docs because it uses os.path.normpath() to normalize the case which is identity in os = posix environments. The call to normpath should be replaced by a call to string.lower() (as it would be done in normpath) From guido@CNRI.Reston.VA.US Thu Nov 11 11:56:05 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 11 Nov 1999 06:56:05 -0500 (EST) Subject: [Python-bugs-list] fnmatch.fnmatch (PR#127) Message-ID: <199911111156.GAA14466@python.org> > Full_Name: Dr. Andreas Amoroso > Version: 1.5.2 > OS: Solaris > Submission from: slspu2.alcatel.de (194.113.59.80) > > > The function fnmatch.fnmatch() is not case-insensitive as described in > the docs because it uses os.path.normpath() to normalize the case which > is identity in os = posix environments. The call to normpath should be > replaced by a call to string.lower() (as it would be done in normpath) You misunderstood the docs. It is only case insensitive IF THE OS IS CASE INSENSITIVE. This is exactly what normpath() is for. --Guido van Rossum (home page: http://www.python.org/~guido/) From gduzan@gte.com Fri Nov 12 23:21:01 1999 From: gduzan@gte.com (gduzan@gte.com) Date: Fri, 12 Nov 1999 18:21:01 -0500 (EST) Subject: [Python-bugs-list] AIX, xlC, and C++ Modules (PR#128) Message-ID: <199911122321.SAA20445@python.org> This is a multi-part message in MIME format. --------------AF969A4820AE6DAE5A453E12 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit While working on a port of the new OmniORBpy stuff to AIX, I came across an interesting issue with python's module loader. importdl.c uses the load() call on AIX to do the loading, which does fine with C and a fair amount of C++. However, the C++ module I was trying to load includes static variables with constructors, and AIX's load() call doesn't handle them properly. To do so, you have to go to the C++ side of the house and call loadAndInit(), which is otherwise identical but does the initialization properly. I'll include the changes that work for me below. I also tried reverting to dlopen(), but this seemed not to resolve the Py_InitModule symbol correctly, leading to a quick core dump. The patch enclosed fixes the problem for me. If anyone else can suggest a better alternative, I'd be glad to hear it. Setup: AIX 4.2.1, C Set++ (xlC) 3.1.4, --with_thread, CC=xlC_r. Gary Duzan GTE Laboratories --------------AF969A4820AE6DAE5A453E12 Content-Type: text/plain; charset=us-ascii; name="python_importdl_patch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="python_importdl_patch.txt" --- Python-1.5.2/Python/importdl.c Wed Jan 27 12:53:10 1999 +++ Python-1.5.2/Python/importdl.c.new Fri Nov 12 17:50:50 1999 @@ -178,7 +178,12 @@ #define DYNAMIC_LINK #define SHORT_EXT ".so" #define LONG_EXT "module.so" +#ifdef USE_SHLIB +#include +#else #include +#include "/usr/lpp/xlC/include/load.h" +#endif typedef void (*dl_funcptr)(); #define _DL_FUNCPTR_DEFINED static int aix_getoldmodules(void **); @@ -458,7 +463,7 @@ p = (dl_funcptr) dlsym(handle, funcname); } #endif /* USE_SHLIB */ -#ifdef _AIX +#if defined(_AIX) && !defined(USE_SHLIB) /* -- Invoke load() with L_NOAUTODEFER leaving the imported symbols -- of the shared module unresolved. Thus we have to resolve them @@ -473,7 +478,8 @@ if (!staticmodlistptr) if (aix_getoldmodules(&staticmodlistptr) == -1) return NULL; - p = (dl_funcptr) load(pathname, L_NOAUTODEFER, 0); + /* p = (dl_funcptr) load(pathname, L_NOAUTODEFER, 0); */ + p = (dl_funcptr) loadAndInit(pathname, L_NOAUTODEFER, 0); if (p == NULL) { aix_loaderror(pathname); return NULL; @@ -877,7 +883,7 @@ } -#ifdef _AIX +#if defined(_AIX) && !defined(USE_SHLIB) #include /* for isdigit() */ #include /* for global errno */ --------------AF969A4820AE6DAE5A453E12-- From bgdarnel@unity.ncsu.edu Sat Nov 13 21:14:39 1999 From: bgdarnel@unity.ncsu.edu (bgdarnel@unity.ncsu.edu) Date: Sat, 13 Nov 1999 16:14:39 -0500 (EST) Subject: [Python-bugs-list] Documentation error for struct module (PR#129) Message-ID: <199911132114.QAA22917@python.org> Full_Name: Ben Darnell Version: 1.5.2 OS: n/a Submission from: sull-05-67.rh.ncsu.edu (152.7.60.67) The Library reference for the struct module says that the 'L' (unsigned long) format character returns a Python int, when in fact it returns a Python long. From fdrake@acm.org Mon Nov 15 14:25:08 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Mon, 15 Nov 1999 09:25:08 -0500 (EST) Subject: [Python-bugs-list] Documentation error for struct module (PR#129) In-Reply-To: <199911132114.QAA22917@python.org> References: <199911132114.QAA22917@python.org> Message-ID: <14384.6084.386423.112829@weyr.cnri.reston.va.us> bgdarnel@unity.ncsu.edu writes: > The Library reference for the struct module says that the 'L' (unsigned long) > format character returns a Python int, when in fact it returns a Python long. Ben, I've fixed this in the documentation sources; it will be reflected in the next documentation release. Thanks for the sharp eye on the documentation! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Mon Nov 15 14:25:04 1999 From: fdrake@acm.org (fdrake@acm.org) Date: Mon, 15 Nov 1999 09:25:04 -0500 (EST) Subject: [Python-bugs-list] Documentation error for struct module (PR#129) Message-ID: <199911151425.JAA25342@python.org> bgdarnel@unity.ncsu.edu writes: > The Library reference for the struct module says that the 'L' (unsigned long) > format character returns a Python int, when in fact it returns a Python long. Ben, I've fixed this in the documentation sources; it will be reflected in the next documentation release. Thanks for the sharp eye on the documentation! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From grant.griffin@alliedsignal.com Mon Nov 15 20:26:47 1999 From: grant.griffin@alliedsignal.com (grant.griffin@alliedsignal.com) Date: Mon, 15 Nov 1999 15:26:47 -0500 (EST) Subject: [Python-bugs-list] TCL_LIBRARY variable for win32 (PR#130) Message-ID: <199911152026.PAA05337@python.org> Full_Name: Grant Griffin Version: 1.5.2 OS: Windows NT 4.0 Submission from: tmpce001.alliedsignal.com (208.238.117.8) 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 From guido@CNRI.Reston.VA.US Mon Nov 15 20:35:20 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Mon, 15 Nov 1999 15:35:20 -0500 (EST) Subject: [Python-bugs-list] TCL_LIBRARY variable for win32 (PR#130) Message-ID: <199911152035.PAA05686@python.org> > 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/) From rushing@eGroups.net Thu Nov 18 06:07:53 1999 From: rushing@eGroups.net (rushing@eGroups.net) Date: Thu, 18 Nov 1999 01:07:53 -0500 (EST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) Message-ID: <199911180607.BAA25074@python.org> Full_Name: Sam Rushing Version: 1.5.2 OS: linux, bsd Submission from: s0-106-a-gte.br5.blv.nwnexus.net (206.63.253.91) list.sort() with a sort function appears broken. >>> l = [23, 342, 17] >>> l [23, 342, 17] >>> l.sort (lambda a,b: a > b) >>> l [23, 342, 17] >>> From mhammond@skippinet.com.au Thu Nov 18 06:57:34 1999 From: mhammond@skippinet.com.au (Mark Hammond) Date: Thu, 18 Nov 1999 17:57:34 +1100 Subject: [Python-bugs-list] list.sort() with sort function (PR#131) In-Reply-To: <199911180607.BAA25074@python.org> Message-ID: <001701bf3192$31dfccc0$0501a8c0@bobcat> Hi Sam, This isnt a bug - sort should have a 3 outcome "cmp" style function. Check out http://x25.deja.com/viewthread.xp?AN=541957314 for a recent thread on the subject, and particularly the referenced message by Tim Peters, which goes into excruciating detail about the implementation... Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > rushing@eGroups.net > Sent: Thursday, 18 November 1999 5:08 > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] list.sort() with sort function (PR#131) > > > Full_Name: Sam Rushing > Version: 1.5.2 > OS: linux, bsd > Submission from: s0-106-a-gte.br5.blv.nwnexus.net (206.63.253.91) > > > list.sort() with a sort function appears broken. > > >>> l = [23, 342, 17] > >>> l > [23, 342, 17] > >>> l.sort (lambda a,b: a > b) > >>> l > [23, 342, 17] > >>> From mhammond@skippinet.com.au Thu Nov 18 06:59:33 1999 From: mhammond@skippinet.com.au (mhammond@skippinet.com.au) Date: Thu, 18 Nov 1999 01:59:33 -0500 (EST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) Message-ID: <199911180659.BAA27465@python.org> Hi Sam, This isnt a bug - sort should have a 3 outcome "cmp" style function. Check out http://x25.deja.com/viewthread.xp?AN=541957314 for a recent thread on the subject, and particularly the referenced message by Tim Peters, which goes into excruciating detail about the implementation... Mark. > -----Original Message----- > From: python-bugs-list-admin@python.org > [mailto:python-bugs-list-admin@python.org]On Behalf Of > rushing@eGroups.net > Sent: Thursday, 18 November 1999 5:08 > To: python-bugs-list@python.org > Cc: bugs-py@python.org > Subject: [Python-bugs-list] list.sort() with sort function (PR#131) > > > Full_Name: Sam Rushing > Version: 1.5.2 > OS: linux, bsd > Submission from: s0-106-a-gte.br5.blv.nwnexus.net (206.63.253.91) > > > list.sort() with a sort function appears broken. > > >>> l = [23, 342, 17] > >>> l > [23, 342, 17] > >>> l.sort (lambda a,b: a > b) > >>> l > [23, 342, 17] > >>> From tim_one@email.msn.com Thu Nov 18 07:08:52 1999 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Thu, 18 Nov 1999 02:08:52 -0500 (EST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) Message-ID: <199911180708.CAA27790@python.org> > Full_Name: Sam Rushing > Version: 1.5.2 > OS: linux, bsd > Submission from: s0-106-a-gte.br5.blv.nwnexus.net (206.63.253.91) > > > list.sort() with a sort function appears broken. > > >>> l = [23, 342, 17] > >>> l > [23, 342, 17] > >>> l.sort (lambda a,b: a > b) > >>> l > [23, 342, 17] > >>> Not a bug. Amazingly enough, see thread "Python 1.5.2 list sorting bug" from just a couple weeks ago (on comp.lang.python) for detailed discussion. Short course: unless you're trying to be excruciatingly clever, as the docs say the sort function must be cmp-like, returning -1 (anything < 0) for <, 0 for ==, +1 (anything > 0)for >. "a > b" returns 0 for a <= b, so confuses equality with inequality. If the intent of the above was to sort in reverse order, >>> l.sort(lambda a, b: cmp(b, a)) >>> l [342, 23, 17] >>> or, quicker, >>> l.sort() >>> l.reverse() >>> l [342, 23, 17] >>> From tim_one@email.msn.com Thu Nov 18 07:08:04 1999 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 18 Nov 1999 02:08:04 -0500 Subject: [Python-bugs-list] list.sort() with sort function (PR#131) In-Reply-To: <199911180607.BAA25074@python.org> Message-ID: <000401bf3193$a90824e0$de2d153f@tim> > Full_Name: Sam Rushing > Version: 1.5.2 > OS: linux, bsd > Submission from: s0-106-a-gte.br5.blv.nwnexus.net (206.63.253.91) > > > list.sort() with a sort function appears broken. > > >>> l = [23, 342, 17] > >>> l > [23, 342, 17] > >>> l.sort (lambda a,b: a > b) > >>> l > [23, 342, 17] > >>> Not a bug. Amazingly enough, see thread "Python 1.5.2 list sorting bug" from just a couple weeks ago (on comp.lang.python) for detailed discussion. Short course: unless you're trying to be excruciatingly clever, as the docs say the sort function must be cmp-like, returning -1 (anything < 0) for <, 0 for ==, +1 (anything > 0)for >. "a > b" returns 0 for a <= b, so confuses equality with inequality. If the intent of the above was to sort in reverse order, >>> l.sort(lambda a, b: cmp(b, a)) >>> l [342, 23, 17] >>> or, quicker, >>> l.sort() >>> l.reverse() >>> l [342, 23, 17] >>> From rushing@eGroups.net Thu Nov 18 07:10:10 1999 From: rushing@eGroups.net (Sam Rushing) Date: Wed, 17 Nov 1999 23:10:10 -0800 (PST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) In-Reply-To: <001701bf3192$31dfccc0$0501a8c0@bobcat> References: <199911180607.BAA25074@python.org> <001701bf3192$31dfccc0$0501a8c0@bobcat> Message-ID: <14387.42578.224182.313582@seattle.nightmare.com> Mark Hammond writes: > This isnt a bug - sort should have a 3 outcome "cmp" style function. Oops, remove foot from mouth. Damn, I never find any bugs in Python. Maybe someone could put a small one in there just for me to find. 8^) -Sam From rushing@eGroups.net Thu Nov 18 07:09:59 1999 From: rushing@eGroups.net (rushing@eGroups.net) Date: Thu, 18 Nov 1999 02:09:59 -0500 (EST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) Message-ID: <199911180709.CAA27911@python.org> Mark Hammond writes: > This isnt a bug - sort should have a 3 outcome "cmp" style function. Oops, remove foot from mouth. Damn, I never find any bugs in Python. Maybe someone could put a small one in there just for me to find. 8^) -Sam From rushing@eGroups.net Thu Nov 18 07:18:43 1999 From: rushing@eGroups.net (Sam Rushing) Date: Wed, 17 Nov 1999 23:18:43 -0800 (PST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) In-Reply-To: <000401bf3193$a90824e0$de2d153f@tim> References: <199911180607.BAA25074@python.org> <000401bf3193$a90824e0$de2d153f@tim> Message-ID: <14387.43091.926061.397907@seattle.nightmare.com> Tim Peters writes: > Not a bug. Amazingly enough, see thread "Python 1.5.2 list sorting bug" > from just a couple weeks ago (on comp.lang.python) for detailed discussion. I guess what turned off my search-usenet instincts is that I *knew* that it used to work that way... I even passed the example on to others to defend against temporary insanity. > If the intent of the above was to sort in reverse order, > > >>> l.sort(lambda a, b: cmp(b, a)) > >>> l > [342, 23, 17] > >>> > > or, quicker, > > >>> l.sort() > >>> l.reverse() > >>> l > [342, 23, 17] > >>> This is what I usually do - I pull the sort key to the front of a tuple and use sort(). In this case I had a small amount of data, and I was sorting on a field buried two tuples deep. I trivialized the example to expose the 'bug' in its simplest form. Sorry for the false alarm! But I learn that all sorts of interesting people are hiding behind the faceless python bug-reporting system. 8^) -Sam From rushing@eGroups.net Thu Nov 18 07:18:28 1999 From: rushing@eGroups.net (rushing@eGroups.net) Date: Thu, 18 Nov 1999 02:18:28 -0500 (EST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) Message-ID: <199911180718.CAA28111@python.org> Tim Peters writes: > Not a bug. Amazingly enough, see thread "Python 1.5.2 list sorting bug" > from just a couple weeks ago (on comp.lang.python) for detailed discussion. I guess what turned off my search-usenet instincts is that I *knew* that it used to work that way... I even passed the example on to others to defend against temporary insanity. > If the intent of the above was to sort in reverse order, > > >>> l.sort(lambda a, b: cmp(b, a)) > >>> l > [342, 23, 17] > >>> > > or, quicker, > > >>> l.sort() > >>> l.reverse() > >>> l > [342, 23, 17] > >>> This is what I usually do - I pull the sort key to the front of a tuple and use sort(). In this case I had a small amount of data, and I was sorting on a field buried two tuples deep. I trivialized the example to expose the 'bug' in its simplest form. Sorry for the false alarm! But I learn that all sorts of interesting people are hiding behind the faceless python bug-reporting system. 8^) -Sam From tim_one@email.msn.com Thu Nov 18 07:29:48 1999 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 18 Nov 1999 02:29:48 -0500 Subject: [Python-bugs-list] list.sort() with sort function (PR#131) In-Reply-To: <14387.43091.926061.397907@seattle.nightmare.com> Message-ID: <000501bf3196$b212dfa0$de2d153f@tim> [Sam Rushing] > I guess what turned off my search-usenet instincts is that I *knew* > that it used to work that way... I even passed the example on to > others to defend against temporary insanity. list.sort() actually never worked that way, although before 1.5.2 it was very likely to appear to work that way for relatively small lists. I shudder to imagine how many people based results on not-really-sorted large lists after seeing this "work" on small lists in interactive mode! I'm delighted I broke it . get-thee-up-and-sin-no-more-ly y'rs - tim From tim_one@email.msn.com Thu Nov 18 07:30:36 1999 From: tim_one@email.msn.com (tim_one@email.msn.com) Date: Thu, 18 Nov 1999 02:30:36 -0500 (EST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) Message-ID: <199911180730.CAA28469@python.org> [Sam Rushing] > I guess what turned off my search-usenet instincts is that I *knew* > that it used to work that way... I even passed the example on to > others to defend against temporary insanity. list.sort() actually never worked that way, although before 1.5.2 it was very likely to appear to work that way for relatively small lists. I shudder to imagine how many people based results on not-really-sorted large lists after seeing this "work" on small lists in interactive mode! I'm delighted I broke it . get-thee-up-and-sin-no-more-ly y'rs - tim From guido@CNRI.Reston.VA.US Thu Nov 18 12:31:37 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 18 Nov 1999 07:31:37 -0500 Subject: [Python-bugs-list] list.sort() with sort function (PR#131) In-Reply-To: Your message of "Thu, 18 Nov 1999 02:30:36 EST." <199911180730.CAA28469@python.org> References: <199911180730.CAA28469@python.org> Message-ID: <199911181231.HAA03641@eric.cnri.reston.va.us> Glad this has been taken care of while I was asleep :-) One more detail: with the current implementation, you can actually get away with a function that returns -1 for less than and 0 for greater than or equal -- but don't tell anybody, since that's an artefact of the implementation (by Tim Peters :-). --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Nov 18 12:31:30 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 18 Nov 1999 07:31:30 -0500 (EST) Subject: [Python-bugs-list] list.sort() with sort function (PR#131) Message-ID: <199911181231.HAA11896@python.org> Glad this has been taken care of while I was asleep :-) One more detail: with the current implementation, you can actually get away with a function that returns -1 for less than and 0 for greater than or equal -- but don't tell anybody, since that's an artefact of the implementation (by Tim Peters :-). --Guido van Rossum (home page: http://www.python.org/~guido/) From aa8vb@yahoo.com Thu Nov 18 13:16:57 1999 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Thu, 18 Nov 1999 08:16:57 -0500 (EST) Subject: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Message-ID: <199911181316.IAA12709@python.org> 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.) From guido@CNRI.Reston.VA.US Thu Nov 18 15:41:31 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 18 Nov 1999 10:41:31 -0500 Subject: [Python-bugs-list] Tkinter missing button state symbols (PR#132) In-Reply-To: Your message of "Thu, 18 Nov 1999 08:16:57 EST." <199911181316.IAA12709@python.org> References: <199911181316.IAA12709@python.org> Message-ID: <199911181541.KAA03942@eric.cnri.reston.va.us> > 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/) From guido@CNRI.Reston.VA.US Thu Nov 18 15:41:17 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 18 Nov 1999 10:41:17 -0500 (EST) Subject: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Message-ID: <199911181541.KAA16995@python.org> > 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/) From aa8vb@yahoo.com Thu Nov 18 18:34:45 1999 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Thu, 18 Nov 1999 13:34:45 -0500 (EST) Subject: [Python-bugs-list] Tkinter canvas blow-up: bbox(ALL) == None (PR#133) Message-ID: <199911181834.NAA21901@python.org> Full_Name: Randall Hopper Version: 1.5.2 OS: IRIX 6.5 Submission from: ethyl-f.rtpfddi.epa.gov (134.67.65.11) 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() From Hopper.Randall@epa.gov Thu Nov 18 19:03:59 1999 From: Hopper.Randall@epa.gov (Hopper.Randall@epa.gov) Date: Thu, 18 Nov 1999 14:03:59 -0500 (EST) Subject: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Message-ID: <199911181903.OAA22522@python.org> 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 From Hopper.Randall@epa.gov Thu Nov 18 19:04:13 1999 From: Hopper.Randall@epa.gov (Randall Hopper) Date: Thu, 18 Nov 1999 14:04:13 -0500 Subject: [Python-bugs-list] Tkinter missing button state symbols (PR#132) In-Reply-To: <199911181541.KAA03942@eric.cnri.reston.va.us> References: <199911181316.IAA12709@python.org> <199911181541.KAA03942@eric.cnri.reston.va.us> Message-ID: <19991118140413.A909863@vislab.epa.gov> 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 From guido@CNRI.Reston.VA.US Thu Nov 18 19:05:57 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 18 Nov 1999 14:05:57 -0500 Subject: [Python-bugs-list] Tkinter missing button state symbols (PR#132) In-Reply-To: Your message of "Thu, 18 Nov 1999 14:03:59 EST." <199911181903.OAA22522@python.org> References: <199911181903.OAA22522@python.org> Message-ID: <199911181905.OAA04683@eric.cnri.reston.va.us> Yes, requests are okay. Sorry for the confusion. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Thu Nov 18 19:05:46 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Thu, 18 Nov 1999 14:05:46 -0500 (EST) Subject: [Python-bugs-list] Tkinter missing button state symbols (PR#132) Message-ID: <199911181905.OAA22646@python.org> Yes, requests are okay. Sorry for the confusion. --Guido van Rossum (home page: http://www.python.org/~guido/) From DrMalte@ddd.de Sun Nov 21 05:01:55 1999 From: DrMalte@ddd.de (DrMalte@ddd.de) Date: Sun, 21 Nov 1999 00:01:55 -0500 (EST) Subject: [Python-bugs-list] python segfaults in PyNode_AddChild (PR#134) Message-ID: <199911210501.AAA28397@python.org> Full_Name: Malte John Version: 1.5.2 and 1.4 OS: Linux 2.0.38, 2.2.10 Submission from: router.ddd.de (212.105.193.65) Hi, both versions of Python can be segfaulted with python -c 'eval( "["+"1,"*16384+"1]" )' or by executing files with arrays with more than 16384 elements. This is caused by an overflow of short n_nchildren of struct _node (Include/node.h) in function PyNode_AddChild (Parser/node.c) Changing the type of "n_nchildren" to int helps only temporarily as the first compilation works, but the import of the compiled file gives a segfault again. My Solution: check for overflow of nch1 in PyNode_AddChild in Parser/node.c like if( ((short)nch1) < 0 ) return NULL; This gives: shift: no mem in addchild Traceback (innermost last): File "", line 1, in ? MemoryError which is the pythonic way! Regards, Malte PS: on Solaris only python-1.4 was available for testing python -c 'eval( "["+"1,"*16384+"1]" )' gives Traceback (innermost last): File "", line 1, in ? SystemError: com_addbyte: byte out of range but python -c 'eval( "["+"1,"*17000+"1]" )' gives Segmentation fault From leroy@iupchbio.univ-nantes.fr Tue Nov 23 16:15:58 1999 From: leroy@iupchbio.univ-nantes.fr (leroy@iupchbio.univ-nantes.fr) Date: Tue, 23 Nov 1999 11:15:58 -0500 (EST) Subject: [Python-bugs-list] A little bug in the ._test of the mailbox module (PR#135) Message-ID: <199911231615.LAA21053@python.org> Full_Name: LEROY Regis Version: 1.5 OS: Linux RH 6.1 Submission from: helios.iupchbio.sciences.univ-nantes.fr (193.52.108.130) I were trying to understand the not so well docummented mailbox module. I've test it with is _test function and I've seen this bug:. >>/test.py /var/spool/mail/leroy 2 Message 2 body: Traceback (innermost last): File "./test.py", line 13, in ? mb = mailbox._test() File "/usr/lib/python1.5/mailbox.py", line 263, in _test msg.rewindbody() File "/usr/lib/python1.5/rfc822.py", line 104, in rewindbody self.fp.seek(self.startofbody) AttributeError: 'None' object has no attribute 'seek' This is due to the line 258 of mailbox.py. In this line we've got "msg.fp = None" (I can't understan why...) So in rfc822 when we make the self.fp.seek fp is None. There is an easy solution which is to comment the line 258 in mailbox.py. I think this should be important for such module. I think it could be important as well to make it more clear, using some documentation strings and talking about the rfc822 msg format. That's all, python is nice langage but geeks are geeks... From fdrake@acm.org Tue Nov 23 16:58:04 1999 From: fdrake@acm.org (fdrake@acm.org) Date: Tue, 23 Nov 1999 11:58:04 -0500 (EST) Subject: [Python-bugs-list] A little bug in the ._test of the mailbox module (PR#135) Message-ID: <199911231658.LAA23088@python.org> leroy@iupchbio.univ-nantes.fr writes: > This is due to the line 258 of mailbox.py. In this line we've got "msg.fp = > None" > (I can't understan why...) I don't either, but it may be there to limit memory consumption. > using some documentation strings and talking about the rfc822 msg format. I may be able to work in some docstrings for the mailbox module. The documentation for the rfc822 module refers to the actual RFC; if you're using the HTML version of the documentation you should be able to follow that link to read the text of the RFC, which contains more than you could possibly want to know about the syntax of RFC 822 headers. I'd hate to summarize and remove a detail that caused anyone to misunderstand the format (but I might anyway, another day). -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From fdrake@acm.org Tue Nov 23 16:58:17 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Tue, 23 Nov 1999 11:58:17 -0500 (EST) Subject: [Python-bugs-list] A little bug in the ._test of the mailbox module (PR#135) In-Reply-To: <199911231615.LAA21053@python.org> References: <199911231615.LAA21053@python.org> Message-ID: <14394.51113.613478.505372@weyr.cnri.reston.va.us> leroy@iupchbio.univ-nantes.fr writes: > This is due to the line 258 of mailbox.py. In this line we've got "msg.fp = > None" > (I can't understan why...) I don't either, but it may be there to limit memory consumption. > using some documentation strings and talking about the rfc822 msg format. I may be able to work in some docstrings for the mailbox module. The documentation for the rfc822 module refers to the actual RFC; if you're using the HTML version of the documentation you should be able to follow that link to read the text of the RFC, which contains more than you could possibly want to know about the syntax of RFC 822 headers. I'd hate to summarize and remove a detail that caused anyone to misunderstand the format (but I might anyway, another day). -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From aa8vb@yahoo.com Wed Nov 24 14:50:52 1999 From: aa8vb@yahoo.com (aa8vb@yahoo.com) Date: Wed, 24 Nov 1999 09:50:52 -0500 (EST) Subject: [Python-bugs-list] WebBugRptBroken & "Python mymalloc.h; not C++ compatible" (PR#136) Message-ID: <199911241450.JAA29362@python.org> Just tried to submit this via the web interface which has worked in the past. This time, I got: The system encountered a fatal error After command: Received: The last error code was: Connection refused This was a non-private bug report, as usual. Anyway, here's the bug report: ============================================================================== aa8vb@yahoo.com Python mymalloc.h; not C++ compatible Randall Hopper 1.5.2 IRIX 6.5 Private: NO 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. Here's a snip from a recent Python post I made with a proposed fix: ------------------------------------------------------------------------------ ...After a bit of grepping, the culprit seems to be Python (1.5.2): /usr/local/include/python1.5/mymalloc.h: #ifndef NULL #define NULL ((ANY *)0) #endif ... It appears to me that the right fix is for Python's mymalloc.h, if it must define NULL (does it?), be updated to be more C++ friendly. E.g.: #ifndef NULL # ifdef __cplusplus # define NULL 0 # else # define NULL ((ANY *)0) # endif #endif I'm assuming there's some reason we can't just #include from mymalloc.h (?) ------------------------------------------------------------------------------ Thanks, Randall From alan2005@ingenieros.com Sat Nov 27 18:26:31 1999 From: alan2005@ingenieros.com (alan2005@ingenieros.com) Date: Sat, 27 Nov 1999 13:26:31 -0500 (EST) Subject: [Python-bugs-list] PRIVATE: Python (PR#137) Message-ID: <199911271826.NAA24153@python.org> Full_Name: alan alanguia paz Version: ultima version OS: windows Submission from: (NULL) (200.37.7.8) sendt please python alan alanguia From alan2005@ingenieros.com Sat Nov 27 18:30:05 1999 From: alan2005@ingenieros.com (alan2005@ingenieros.com) Date: Sat, 27 Nov 1999 13:30:05 -0500 (EST) Subject: [Python-bugs-list] Python (PR#138) Message-ID: <199911271830.NAA24195@python.org> Full_Name: alan alanguia paz Version: ultima version OS: windows Submission from: (NULL) (200.37.7.8) sendt thand python please alan alanguia From taliesin@nvg.org Sun Nov 28 03:53:55 1999 From: taliesin@nvg.org (taliesin@nvg.org) Date: Sat, 27 Nov 1999 22:53:55 -0500 (EST) Subject: [Python-bugs-list] mktime fails on specific dates (PR#139) Message-ID: <199911280353.WAA01135@python.org> Full_Name: Version: 1.5.2 OS: FreeBSD, NetBSD, OpenBSD, Solaris, A/UX Submission from: rhiann.nvg.ntnu.no (129.241.210.114) I was comparing dates the other day... mktime(3), used by the time-module and indirectly by the rfc822-module, returns -1 for some dates on at least the mentioned os'es, for instance the date 'Sun, 28 Mar 1999 02:19:47'. The time-module raises an OverflowError, but as mktime *does* return a float for the above date on for instance linux, aix, irix, dec-unix and hp-ux (haven't tested more systems than that), it would be nice if python could catch this somehow, for portability's sake. solaris & freebsd: Sun 28 Mar 1999 01:19:47 == 922580387.0 Sun 28 Mar 1999 02:19:47 == -1 Sun 28 Mar 1999 03:19:47 == 922583987.0 aix: Sun 28 Mar 1999 01:19:47 == 922580387.0 Sun 28 Mar 1999 02:19:47 and Sun 28 Mar 1999 03:19:47 == 922587587.0 linux w/MET: Sun 28 Mar 1999 01:19:47 MET == 922580387.0 Sun 28 Mar 1999 02:19:47 MET == 922580387.0 Sun 28 Mar 1999 03:19:47 MET == 922587587.0 This is a Daylights Saving Time-issue according to the bugfixers at FreeBSD, mktime uses the dst-info on the machine it runs on. It won't be fixed from their end, see for instance: http://www.freebsd.org/cgi/query-pr.cgi?pr=13862 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 :) t. From a07498@ctv.es Sun Nov 28 18:23:41 1999 From: a07498@ctv.es (a07498@ctv.es) Date: Sun, 28 Nov 1999 13:23:41 -0500 (EST) Subject: [Python-bugs-list] RENTA MENSUAL (PR#140) Message-ID: <199911281823.NAA14620@python.org> De inicio le ofrecemos 1.000.-pts de regalo y el 5% de su facturacion, Y LO MISMO DE SUS AMIGOS O CLIENTES, vealo en http://www.ctv.es/USER/a07498 ------------------------------------------------- Su direccion sera borrada de esta lista de no comunicarnos lo contrario, disculpe las molestias esta es una oferta de trabajo, quizas a usted no le interese, pero siempre puede ofrecerselo a un amigo, familiar o alguien que le interese, o lo necesite, en cualquier caso solo rellenando el formulario obtendra las ventajas. From guido@CNRI.Reston.VA.US Sun Nov 28 21:42:41 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Sun, 28 Nov 1999 16:42:41 -0500 Subject: [Python-bugs-list] Python (PR#138) In-Reply-To: Your message of "Sat, 27 Nov 1999 13:30:05 EST." <199911271830.NAA24195@python.org> References: <199911271830.NAA24195@python.org> Message-ID: <199911282142.QAA06659@eric.cnri.reston.va.us> > Full_Name: alan alanguia paz > Version: ultima version > OS: windows > Submission from: (NULL) (200.37.7.8) > > > sendt thand python > please > > alan alanguia I believe this bug report was received in error. I don't understand the nature of the bug. --Guido van Rossum (home page: http://www.python.org/~guido/) From guido@CNRI.Reston.VA.US Sun Nov 28 21:42:36 1999 From: guido@CNRI.Reston.VA.US (guido@CNRI.Reston.VA.US) Date: Sun, 28 Nov 1999 16:42:36 -0500 (EST) Subject: [Python-bugs-list] Python (PR#138) Message-ID: <199911282142.QAA17272@python.org> > Full_Name: alan alanguia paz > Version: ultima version > OS: windows > Submission from: (NULL) (200.37.7.8) > > > sendt thand python > please > > alan alanguia I believe this bug report was received in error. I don't understand the nature of the bug. --Guido van Rossum (home page: http://www.python.org/~guido/) From newsreporter@rciinfo.com Mon Nov 29 20:23:31 1999 From: newsreporter@rciinfo.com (newsreporter@rciinfo.com) Date: Mon, 29 Nov 1999 15:23:31 -0500 (EST) Subject: [Python-bugs-list] Finding Good Human Resource Candidates (PR#141) Message-ID: <199911292023.PAA17139@python.org> The competition for finding good Human Resource candidates if fierce! However, there is an edge - and we want you to have it FREE! BestJobsUSA.com will run all of your Human Resource category positions free. No catch. Nothing to buy. No obligation whatsoever. At BestJobsUSA.com, we recognize our business is dependent upon getting results for our Human Resource clients. This is just another way to keep you aware of our services. E-mail your Human Resource category positions to us at: mailto:RCI@BestJobsUSA.com. We'll have it up and running within 48 hours. If this isn't your function please forward on to the appropriate person. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- We also want to make you aware of our WebRunner resume retrieval technology. WebRunner will deliver resumes that meet your specific job criteria quickly and cost effectively. This service is available now for the low cost of $400.00 per search. Simply provide us with the with job description, or key words (competitors you would like to target…) and we do all the work. For full information, contact Gregg Lowenstein at mailto:glowenstein@rcimedia.com or telephone at (561)686-6800, ext. 314 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This information has been e-mailed to keep you apprised of recruitment-advertising opportunities. If this information is not suitable for your area of responsibility or if you want to be removed from our distribution list, please e-mail mailto:nothankyou@rcimedia.com?subject=HR From dbt@meat.net Tue Nov 30 11:26:31 1999 From: dbt@meat.net (dbt@meat.net) Date: Tue, 30 Nov 1999 06:26:31 -0500 (EST) Subject: [Python-bugs-list] dircache can't distinguish between empty directories and nonexistant ones (PR#142) Message-ID: <199911301126.GAA03849@python.org> Full_Name: David Terrell Version: 1.5.2 OS: OpenBSD 2.6 Submission from: luciana.catch22.org (209.157.133.198) It seems like this would be the ideal place to use some sort of exception. It seems silly to do a stat on it myself then call dircache which does the same thing. Python 1.5.2 (#2, Nov 27 1999, 14:43:38) [GCC 2.95.1 19990816 (release)] on openbsd2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import dircache >>> dircache.listdir("/altroot") [] >>> dircache.listdir("/foobarbleh") [] >>> ^D dbt@luciana:src/python>ls -d /altroot /foobarbleh ls: /foobarbleh: No such file or directory /altroot