> One related issue is testing these, how can a NaN and +/-Infinity 
> float object be created in Python?

In 2.6 and 3.0 (but not 2.5 and older), float('nan'), float('inf') and 
float('-inf') should all work reliably across platforms (or at least 
those platforms that support infs and nans).  If they don't it's a bug.

> (2) On your 2nd comment, supporting non-IEEE floating point, perhaps
> the Kahan method should be used in that case.  If so, the next
> question is how to detect that?

Actually, I think you could probably just leave the algorithm exactly as 
it is, but put a warning in the documentation that the exactness only 
applies in the presence of IEEE 754 semantics.  Practically everybody's 
on an IEEE 754 platform anyway.

> There are two symbols in pyconfig.h HAVE_IEEEFP_H and
> HAVE_LIBIEEE.  Are those the proper ones to determine IEEE floating
> point support?

I'm not sure that either of these is the right thing.  Neither is 
defined on my MacBook, for example.

> (3) On the 3rd comment, Raymond and I did discus using a single 
> function to be called by the math and cmath modules.

I think you're right that it's easier to just duplicate the code.
It's a nice feature that this function only has to pass once through the 
data, and it doesn't seem worth losing that to save a little bit of code 
duplication.

I still wonder whether there's a way to avoid incorrectly signaling 
overflow in the case where the result is finite. (e.g. sum([1e308, 
1e308, -1e308])).