In Py3k, but not in trunk:

======================================================================
FAIL: testSum (test.test_math.MathTests)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 769, in
testSum
    self.assertEqual(math.sum(vals), s)
OverflowError: math range error

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 772, in
testSum
    "for math.sum(%.100r)" % (i, s, vals))
AssertionError: test 13 failed: got OverflowError, expected
1.7976931348623157e+308 for math.sum([1.7976931348623157e+308,
9.979201547673598e+291])

System info: linux x86, glibc 2.8

Sadly, this is not the only problem with math.sum on x86 hardware right
now. I'd guess that this is another problem related to double-rounding
and the use of 80-bit floating-point registers on x86. Raymond and I
are still actively looking for ways to fix math.sum up, including the
possibility of a complete rewrite using a totally different algorithm.

With the current algorithm, behaviour at or near the boundary of the
floating-point range should really be considered undefined; so the
quick fix is to update the tests and docs to reflect this. The
particular test that causes test.math to fail would just be removed.

I am intrigued that py3k and the trunk give different results, though;
I'd very much like to know where the difference comes from.

Georg, *only if you have time*, could you please tell me what results
the linux box gives for the following two Python sums, in both py3k and
the trunk:

>>> 1e16 + 2.9999
10000000000000002.0
>>> 1.7976931348623157e+308 + 9.979201547673598e+291
1.7976931348623157e+308

(The results shown are the ones I get on OS X 10.5.4; I don't have
access to a linux box for testing at the moment.)

See also bpo-2819 for ongoing discussion, and bpo-2937, which is the
likely root cause of the current difficulties with math.sum.

Both trunk and 3k give this:

>>> 1e16 + 2.9999
10000000000000004.0
>>> 1.7976931348623157e+308 + 9.979201547673598e+291
inf

Thanks. Those are the results I'd expect on x86. So here's the puzzle:

On lines 658-9 of Lib/test/test_math.py, in revision 65248 of the py3k
branch, there's a pair of lines that looks like:

        if 1e16+2.999 != 1e16+2.9999:
            return

These lines are supposed to bail out of testSum on IEEE 754 hardware
that doesn't do correct rounding. So on your machine, I'd expect:

1e16+2.999 to evaluate to 10000000000000002.0
1e16+2.9999 to evaluate to 10000000000000004.0

so the condition in the if statement ought to be True, and the rest of
the tests should be skipped.

It looks like this bailout is working as intended in the trunk, but not
in Py3k. Any ideas why there's a difference? Is there some sort of
constant folding going on in py3k but not in the trunk?

Strangely, it seems to work now with 3k too -- both in a debug and
release build. I've no idea what changed, but I'll close this for now.

The tests at floating point boundaries should probably be removed and
their behavior should be left undefined.

See also bpo-5593.