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.comhttp://www.zope.org
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
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
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>
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
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
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
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.
Here is my todo list for Py2.3.
Feel free to comment on whether it is too late to pursue these
or whether I should continue to work on them for the second beta.
1) PEP 42 lists a request to add timeout settings to the higher level
net libraries. Should this still be done? In Py2.3, sockets offers
a setdefaulttimeout() function that provides an indirect way of
meeting the same goal.
2) Jack Diedrich is working on two patches for itertools:
itertools.window(iterable, n=2) --> (a0, a1), (a1, a2), (a2, a3), ...
itertools.roundrobin(*iterables) which loops over the iterables
returning one element from each and then cycles back to the
first until all of the iterables are exhausted:
itertools.roundrobin('ab', 'cde') --> a, c, b, d, e
Both functions were discussed on comp.lang.python and have been
requested by multiple users. Neither is easily implemented in terms
of the existing tools. OTOH, the more tools you add, the harder it
is to comprehend the toolset as a whole.
3) difflib now has functions to create a context diff or unified diff.
A natural next step is to add a patch() function that applies the diff
and finishes the roundtrip. It also helps fulfill the original reason for
adding the context/unified diffs which was to make it easier for
general python users to either create or apply patches.
4) I've had a long outstanding patch to add methods like isalpha() to
string objects. The goal was to make sure that replacements exist
for all the tools in the string module. The hold-up has been in
making UniCode equivalents. If this is still wanted, I'll finish it up.
Raymond Hettinger
