Mailman 3 June 2003 - Python-Dev

Bug with ExtensionClass and __coerce__
by Christian Reis June 28, 2003

June 28, 2003

In the next chapter of the war for Persistent.__cmp__, I found a bug in ExtensionClass's handling of __coerce__. Here's a paired-down testcase. from ExtensionClass import Base class Foo(Base): def __coerce__(self, other): return None class Bar(Base): def __coerce__(self, other): return NotImplemented f = Foo(); assert 0 < f -> SystemError: error return without exception set b = Bar(); assert 0 < b -> SystemError: new style getargs format but argument is not a tuple As far as I know (and the PSL docs say) these are the only valid ways to give up __coerce__. Guido has in the past provided a hint to the latter error: http://mail.zope.org/pipermail/zope-coders/2002-January/000594.html Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL

1 0

doctest extensions
by Jim Fulton June 28, 2003

June 28, 2003

I've written some doctest extensions to: - Generate a unitest (pyunit) test suite from a module with doctest tests. Each doc string containing one or more doctest tests becomes a test case. If a test fails, an error message is included in the unittest output that has the module file name and the approximate line number of the docstring containing the failed test formatted in a way understood by emacs error parsing. This is important. ;) - Debug doctest tests. Normally, doctest tests can't be debugged with pdb because, while they are running, doctest has taken over standard output. This tool extracts the tests in a doc string into a separate script and runs pdb on it. - Extract a doctest doc string into a script file. I think that these would be good additions to doctest and propose to add them, The current source can be found here: http://cvs.zope.org/Zope3/src/zope/testing/doctestunit.py?rev=HEAD&content-… I ended up using a slightly different (and simpler) strategy for finding docstrings than doctest uses. This might be an issue. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (703) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

Python 2.3b1, distutils and PEP 263
by pinard＠iro.umontreal.ca June 27, 2003

June 27, 2003

Hi, people. For quite a long time, I noticed that Distutils inserts a supplementary white line when it transforms the shebang line. There might be some reason for this white line, and I'm curious about it. This does not interact nicely with PEP 263. For example, the file: ----------------------------------------------------------------------> #!/usr/bin/env python # -*- coding: Latin-1 -*- """\ [...] ----------------------------------------------------------------------< get installed by Distutils as: ----------------------------------------------------------------------> #!/usr/bin/python # -*- coding: Latin-1 -*- """\ [...] ----------------------------------------------------------------------< and Python 2.3b1 does not see the `coding:' pragma on the third line. -- François Pinard http://www.iro.umontreal.ca/~pinard

4 5

[ANN] SciPy '03 -- The 2nd Annual Python for Scientific Computing Workshop
by eric jones June 27, 2003

June 27, 2003

Hey folks, I've been postponing this announcement because the registration page isn't active yet. It's getting late though, and I thought I'd at least let you know SciPy '03 is happening. I'll repost when registration is open. Thanks, Eric ------------------------------------------------------- SciPy '03 The 2nd Annual Python for Scientific Computing Workshop ------------------------------------------------------- CalTech, Pasadena, CA September 11-12, 2003 http://www.scipy.org/site_content/scipy03 This workshop provides a unique opportunity to learn and affect what is happening in the realm of scientific computing with Python. Attendees will have the opportunity to review the available tools and how they apply to specific problems. By providing a forum for developers to share their Python expertise with the wider industrial, academic, and research communities, this workshop will foster collaboration and facilitate the sharing of software components, techniques and a vision for high level language use in scientific computing. The cost of the workshop is $100.00 and includes 2 breakfasts and 2 lunches on Sept. 11th and 12th, one dinner on Sept. 11th, and snacks during breaks. Online registration is not available yet, but will be soon. We would like to have a wide variety of presenters this year. If you have a paper you would like to present, please contact eric(a)enthought.com. Discussion about the conference may be directed to the SciPy-user mailing list: Mailing list page: http://www.scipy.org/MailList Mailinbg list address: scipy-user(a)scipy.org Please forward this announcement to anyone/list that might be interested. ------------- Co-Hosted By: ------------- The National Biomedical Computation Resource (NBCR, SDSC, San Diego, CA) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://nbcr.sdsc.edu The mission of the National Biomedical Computation Resource at the San Diego Supercomputer Center is to conduct, catalyze, and enable biomedical research by harnessing advanced computational technology. The Center for Advanced Computing Research (CACR, CalTech, Pasadena, CA) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://nbcr.sdsc.edu CACR is dedicated to the pursuit of excellence in the field of high-performance computing, communication, and data engineering. Major activities include carrying out large-scale scientific and engineering applications on parallel supercomputers and coordinating collaborative research projects on high-speed network technologies, distributed computing and database methodologies, and related topics. Our goal is to help further the state of the art in scientific computing. Enthought, Inc. (Austin, TX) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://enthought.com Enthought, Inc. provides scientific and business computing solutions through software development, consulting and training. ---------------------------------------------- eric jones 515 Congress Ave www.enthought.com Suite 1614 512 536-1057 Austin, Tx 78701

1 0

Embedding Python, threading and scalability
by David Abrahams June 27, 2003

June 27, 2003

Sorry to intrude here with this, but I fear this guy's question isn't going to get addressed well on the C++-sig or on python-list, so I was wondering if someone here, who knows, would mind answering him: http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1687739 -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

test_copy_reg failing in 2.3 CVS
by Tim Peters June 27, 2003

June 27, 2003

Here on Win2K: C:\Code\python\PCbuild>python ../lib/test/test_copy_reg.py test_bool (__main__.CopyRegTestCase) ... ok test_class (__main__.CopyRegTestCase) ... ok test_extension_registry (__main__.CopyRegTestCase) ... ok test_noncallable_constructor (__main__.CopyRegTestCase) ... FAIL test_noncallable_reduce (__main__.CopyRegTestCase) ... ok ====================================================================== FAIL: test_noncallable_constructor (__main__.CopyRegTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "../lib/test/test_copy_reg.py", line 23, in test_noncallable_constructor type(1), int, "not a callable") File "C:\Code\python\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: TypeError ---------------------------------------------------------------------- Ran 5 tests in 0.081s FAILED (failures=1) Traceback (most recent call last): File "../lib/test/test_copy_reg.py", line 92, in ? test_main() File "../lib/test/test_copy_reg.py", line 88, in test_main test_support.run_unittest(CopyRegTestCase) File "C:\Code\python\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "C:\Code\python\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "../lib/test/test_copy_reg.py", line 23, in test_noncallable_constructor type(1), int, "not a callable") File "C:\Code\python\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: TypeError C:\Code\python\PCbuild>

1 0

OSCON Lightning Talk Proposals still being accepted
by David Ascher June 25, 2003

June 25, 2003

If you're going to OSCON (http://conferences.oreillynet.com/os2003/) and want to give a very short presentation about something Python-related, send me an email. Please put the word "lightning" in the subject line. The lightning talk session is scheduled for Thursday, from 4:30 till 6:00. We're still accepting proposals, so send one in today! I'll probably be accepting proposals until late in the game, except if the slot fills up. If you've never heard of lightning talks, you can find out more information at: http://perl.plover.com/lt/osc2003/lightning-talks.html But ignore the submission informations on that site, just send me email. See you in Portland, -- David Ascher

1 0

deprecate dbm module & add bsddb185 module for 2.2.x
by Matthias Klose June 25, 2003

June 25, 2003

At least on current Debian systems (testing/unstable), the dbm module cannot be built anymore using the classic ndbm interface. Building this module using the BSD DB compatibility interface, or the GNU GDBM compatibility interface, is not an option, because the file format differs and existing archives cannot be read anymore. I'm unaware of the situation on other Linux systems and other systems. Would it be possible to deprecate the use of the dbm module for 2.3, or is it still used on many systems? Would it be acceptable to backport the bsddb185 module to the 2.2 branch? Matthias

2 1

Py2.1
by Raymond Hettinger June 25, 2003

June 25, 2003

After closing a bug report for something fixed in Py2.2.3 and beyond, I later wondered if it should be left open so that a fix can be made back to Py2.1.4. My question is whether there is going to be another bugfix release for 2.1 or can we limit our open bugs and backports to just 2.2? My own preference is to avoid considering 2.1 because the issues and solutions tend to change as you go back in time. Raymond Hettinger

7 6

Python hash function
by Damien Morton June 24, 2003

June 24, 2003

Ive been doing some investigation of python hashtables and the hash function used in Python. It turns out, that when running pystone.py, as much time is spent in string_hash() as is spent in lookdict_string(). If you look at python's hash function, shown below, you can get an idea why - a multiply is used for every character in the string. The following function, called 2^22 times in a loop, times in at 530ms for 7-character strings. static long string_hash1(register char *p, int size) { register int len; register long x; len = size; x = *p << 7; while (--len >= 0) x = (100003*x) ^ *p++; x ^= size; return x; } Looking around the web I found the following hash function, which is much faster, and seems to distribute better than the python hash function. The following function, called 2^22 times in a loop, times in at 160ms for 7-character strings. static long string_hash3(register char *p, register int size) { register long x; register char c; x = 0xd2d84a61; while (c = *p++) x ^= ( (x<<7) + c + (x>>5) ); return x; } I also came up with a hash function of my own, which seems to distribute near-perfectly (in the sense of being comparable to assigning, as hashes, random numbers to unique strings) and be faster yet (at least, on my P4 box). The following function, called 2^22 times in a loop, times in at 120ms for 7-character strings. static long string_hash6(register unsigned short *p, int size) { register unsigned long x = 0; if (size==0) return 0; len = (size+1) >> 1; while (len--) { x += (x>>14) + (*p++ * 0xd2d84a61); } x += (x>>14) + (size*0xd2d84a61); return x; } Ive tested these functions by hashing a large set of strings generated by instrumenting the python interpeter to emit a string every time a string is added to a dictionary. These strings are hashed and thrown into the buckets of various sized tables. I then calculate sigma statistics (sum((observed-expected)^2)/(N-1)) for the number of items in the buckets of those tables. Here are the sum(sigma) results I am getting in my tests: string_hash1 sum(sigma) ~= 30K string_hash3 sum(sigma) ~= 23-24K string_hash6 sum(sigma) ~= 23-34K string_hashRandom sum(sigma) ~= 23-24K Maddeningly, I havent been able to translate these near-perfect distributions into improvements in pystones. With the current hash function, pystone does an average of 1.2 probes in the lookdict_string() function. With either of these "near-perfect" hash functions, it does at best 1.3 probes (given exhaustive searches for 'good' shift paramaters, though not multipliers). Im not sure what other tests to try out, or how I might go about tweaking the hashes to perform better in pystone. Im hoping that someone on python-dev has some experience in testing hash functions, and can suggest some additional tests and/or tweaks.

3 2