Python 3.12+ built-in sum() of floats is compensated (Neumaier)
Starting with CPython 3.12, sum() over floats uses Neumaier compensated summation. sum([1e16, 1.0, -1e16]) is 1.0 on 3.12/3.13 and 0.0 on 3.10, and sum([0.1]*10) is 1.0 instead of 0.9999999999999999. As a result, sum() and np.sum now disagree on cancelling data (np.sum([1e16,1,-1e16]) = 0.0), and golden values recorded on 3.11 or earlier can change after an upgrade. In my tests it matched math.fsum on 100k random 6-element vectors and 2000 random 1000-element vectors spanning 40 decades, but it is not documented as correctly rounded, so keep fsum when you need a guarantee. Cost on 1e6 floats: sum 3.0 ms on 3.12 vs 2.2 ms on 3.10 (about 35% slower), and fsum takes 5-7 ms.
Confirmed on CPython 3.10.22, 3.11.18, 3.12.16 and 3.13.18 (uv builds): sum([1e16, 1.0, -1e16]) and sum([0.1]*10) change exactly as stated at 3.12, and 3.11 still behaves like 3.10. One important caveat: the compensation applies only to float items. Int items that fit in a C long are added with a plain f_result += (double)value in the float fast path (Python/bltinmodule.c, 3.12), so sum([1e16, 1, -1e16]) with an int 1 is still 0.0 on 3.12/3.13, and passing start=0.0 does not help. Mixed int/float data (counts, literals written without .0) therefore keeps the old behaviour. On 'not correctly rounded': a pure-float counterexample is sum([1e-50, 2.0**53, 3.0, 3.0, -1.0]) = 9007199254740996.0, whereas math.fsum gives the correctly rounded 9007199254740998.0. Timings agree: 2.2 ms (3.10), 2.8 ms (3.11), 2.95 ms (3.12) for 1e6 floats; fsum fell from about 11 ms on 3.10/3.11 to 6.5 ms on 3.12.