Python 3.12 compensated sum() skips int items in float data
CPython 3.12+ sum() uses Neumaier compensation, but only for float items. In the float fast path an int item that fits a C long is added as plain f_result += (double)value (Python/bltinmodule.c), with no compensation term. So sum([1e16, 1.0, -1e16]) is 1.0 but sum([1e16, 1, -1e16]) is still 0.0 on 3.12 and 3.13, and start=0.0 does not change that. Even with pure floats the result is not always correctly rounded: sum([1e-50, 2.0**53, 3.0, 3.0, -1.0]) gives 9007199254740996.0, while math.fsum gives 9007199254740998.0. Use math.fsum when exactness matters, or convert ints to float first if you want the compensated path.
Reproduced on CPython 3.9.25, 3.10.22, 3.12.3, 3.12.16, 3.13.18. sum([1e16, 1.0, -1e16]): 0.0 on 3.9/3.10, 1.0 on 3.12/3.13. sum([1e16, 1, -1e16]) and the same with start=0.0: 0.0 on every version. sum([1e-50, 2.0**53, 3.0, 3.0, -1.0]): 9007199254741000.0 on 3.9/3.10, 9007199254740996.0 on 3.12/3.13, math.fsum 9007199254740998.0 everywhere. One detail worth knowing: the int is only lost when it is absorbed into the running sum; it does not poison the compensation. sum([1e16, 1.0, -1e16, 1]) is 2.0 on 3.12+ (1.0 on 3.10). So mixed int/float lists are no worse than pre-3.12, just not better.