Mailman 3 June 2003 - Python-Dev

2.3b2 known bugs?
by Neal Norwitz 30 Jun '03

30 Jun '03

These are listed as known bugs in beta2 (pydotorg/2.3/bugs.ht), but I think they are solved: * On Solaris 8, build of the bz2 module failed for one correspondent; this may depend on the specific release or provisioning of the box. * The test for the logging module fails for some people on Solaris and Mac OS X. A patch has been applied to CVS that hopefully fixes this. Skip, I think you had both of these problems. Is everything ok for you? Neal

2 1

Delayed `-i'! :-)
by pinard＠iro.umontreal.ca 30 Jun '03

30 Jun '03

[Fran�ois Pinard, 2003-06-26] > Hi, Python friends. > > Is there a way for a script to activate the effect of the `-i' option, > that is, to force interactive mode once `__main__' has run? [...] Thanks. Setting PYTHONINSPECT solves this matter in 2.3b2, Linux and Windows. -- François Pinard http://www.iro.umontreal.ca/~pinard -- François Pinard http://www.iro.umontreal.ca/~pinard

1 0

Meaty debugging mystery
by Tim Peters 30 Jun '03

30 Jun '03

Neil Schemenauer was running regrtest with -r and got a segfault. He whittled it down to running just -u bsddb test_logging test_bsddb3 This was confirmed on Win2K, Win98, and some version of Linux. He also discovered that the problem went away if test_logging.py's locale.setlocale(locale.LC_ALL, '') was commented out. I've since found that the problem persists if + All the suite.addTest() calls in bsddb/test/test_basics.py are commented out except for suite.addTest(unittest.makeSuite(BTreeMultiDBTestCase)) and + All the entries in test_bsddb3.py's test_modules list are commented out except for 'test_basics', Then running yields this output: test_bsddb3 test01_GetsAndPuts (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test02_DictionaryMethods (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test03_SimpleCursorStuff (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test04_PartialGetAndPut (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test05_GetSize (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test06_Truncate (bsddb.test.test_basics.BTreeMultiDBTestCase) ... ok test09_MultiDB (bsddb.test.test_basics.BTreeMultiDBTestCase) ... FAIL and that's when the crash happens. I don't have time to dig into this more. Looks like a good one, though!

2 1

MDaemon Warning - Virus Found
by postmaster＠mailservice.be 30 Jun '03

30 Jun '03

The following message had attachment(s) which contained viruses:

1 0

Running tests on freebsd5
by PieterB 30 Jun '03

30 Jun '03

Hi, I just checked out the Python CVS head, ran configure and compiled succesfully on FreeBSD 5.0. I then ran 'make tests', and had two failing tests. I don't think these errors are related to FreeBSD5.0, so I post them here. Can somebody add the lists of tests for 'freebsd5' to regrtest.py, and have a look at these tracebacks? PieterB -- http://zwiki.org/PieterB ... 2 tests failed: test_socket test_tempfile 34 tests skipped: test_aepack test_al test_bsddb test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_fcntl test_gdbm test_gl test_imgfile test_ioctl test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Ask someone to teach regrtest.py about which tests are expected to get skipped on freebsd5. ------------------------------------------------------------------ When running test_socket.py, I get the following traceback: Ran 51 tests in 2.470s FAILED (errors=1) Traceback (most recent call last): File "test_socket.py", line 755, in ? test_main() File "test_socket.py", line 752, in test_main test_support.run_unittest(*tests) File ".../src/Lib/test/test_support.py", line 259, in run_unittest run_suite(suite, testclass) File ".../src/Lib/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test_socket.py", line 215, in testCrucialConstants socket.SOCK_RDM AttributeError: 'module' object has no attribute 'SOCK_RDM' ----------------------------------------------------------------- When I run test_tempfile.py I get: Ran 34 tests in 0.703s FAILED (failures=1) Traceback (most recent call last): File "test_tempfile.py", line 651, in ? test_main() File "test_tempfile.py", line 648, in test_main test_support.run_unittest(*test_classes) File ".../src/Lib/test/test_support.py", line 259, in run_unittest run_suite(suite, testclass) File ".../src/Lib/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File ".../src/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure

4 3

ALERT - GroupShield ticket number OA2751_1056939039_ZACAPEX01_3 was generated
by GroupShield for Exchange (ZACAPEX01) 30 Jun '03

30 Jun '03

Action Taken: The attachment was quarantined from the message and replaced with a text file informing the recipient of the action taken. To: personal-premium(a)thawte.com <personal-premium(a)thawte.com> From: python-dev(a)python.org <python-dev(a)python.org> Sent: -556770176,29572780 Subject: Re: Application Attachment Details:- Attachment Name: your_details.zip File: your_details.zip Infected? No Repaired? No Blocked? Yes Deleted? No Virus Name:

1 0

RE: [Python-Dev] Running tests on freebsd5
by Delaney, Timothy C (Timothy) 30 Jun '03

30 Jun '03

> From: Andrew MacIntyre [mailto:andymac@bullseye.apana.org.au] > > On Sun, 29 Jun 2003, PieterB wrote: > > > 2 tests failed: > > test_socket test_tempfile > > I'm aware of these 2, and there are some other niggling issues with > FreeBSD 5.x that I've been looking at. Some of these issues won't > stabilise until the FreeBSD team choose to declare 5.x a > "stable" branch. > 5.0 in particular is not a good release to target for solid support. I might have the opportunity to at least run the tests on FreeBSD 5.1. I just set up my first FreeBSD system on the weekend :) However, it will probably have to wait until the weekend when I have time to actually *configure* the system - I got it to the stage of being able to run KDE and that was it - then I felt I'd earned my chance to watch my "Spirited Away" DVD :) Tim Delaney

1 0

threads duplicated on fork() prevent child from terminating properly
by Hunter Peress 29 Jun '03

29 Jun '03

when i hear redhat 9 and threads....i think of the completely new NTPL threads library just keep that in mind. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

1 0

threads duplicated on fork() prevent child from terminating properly
by L.C. (Laurentiu C. Badea) 29 Jun '03

29 Jun '03

Hello, I am reposting this here as c.l.py didn't produce too many responses... If anybody has any pointers on how to fix (or where to look), I would appreciate it. I've tried this on 2.1 (RedHat 7.3), 2.2.1 and 2.2.3 (RedHat 9). The simple program below launches a thread, then fork()s and attempts to clean the mess up on exit like the nice process it is. Only problem is, the child does not want to die, looks like it detached and is sitting on schedule_timeout() (according to ps). This is, I suspect, because the thread and its state are duplicated on fork() but the state structure is not updated to indicate that the thread is in fact NOT active so the child is fooled into waiting for its termination, which will never happen. If the parent terminates without executing waitpid(), the child will hang there indefinitely wasting resources. I can see the following ways to actually have it finish normally: 1) parent join()-s all the threads before fork(): not always possible. 2) parent kill()-s the child: not nice. 3) child does os._exit(): IMHO the best option but os._exit() is not described as an elegant exit method. Using this also means that if all exceptions are not handled in the thread, we risk the same problem. I guess I have answered 90% of my question (which I have not stated) already. At any rate, it seems to me that this matter should be handled internally in Python's core. Regardless of whether os._exit() is mandated for use in child processes or not instead of sys.exit() or other exception handlers, I find it somewhat illogical to have the child process wait for a thread that is not really there. I would probably expect that os.fork() would clean up the thread list in the child unless we know (Solaris) that the threads are really there. import os, sys from threading import * def log( message ): print ( "%d %s" % (os.getpid(), message) ) if __name__ == "__main__": log( "is parent" ) t = Thread() t.start() # t.join() # OPTION 1 childPID = os.fork() if childPID == 0: log( "is child" ) log( "threads: %s" % str(enumerate()) ) if childPID == 0: #os._exit(0) # OPTION 2 pass else: t.join() #os.kill( childPID, 15 ) # OPTION 3 log( "parent done waiting for %s, now waiting for %d" % (t.getName(), childPID) ) os.waitpid(childPID, 0) log( "exiting" ) Thank you, -- L.C. (Laurentiu Badea)

2 1

Problems in stdlib before 2.3b2
by Neal Norwitz 29 Jun '03

29 Jun '03

There are a couple of problems in the stdlib. These are the most serious ones that I found: trace.py: uses threading.settrace(), but settrace doesn't exist in the threading module staring around line 444 xmlrpclib.py: around line 734, Fault() is instantiated with only keyword arguments, there are 2 required arguments. I don't know how to get the faultCode and faultString. xml/dom/expatbuilder.py: line 272, missing self. before curNode I added this to Python, does this need to go into PyXML? Unfortunately, this was just a quick review. Neal

4 3