Repository navigation
Add more fields to sys.float_info #85989
Description
Activity
Consider adding new non-sequence fields to sys.float_info: doubling_rounding and ieee_754.
The code in test_math defines a useful constant:
# detect evidence of double-rounding: fsum is not always correctly
# rounded on machines that suffer from double rounding.
x, y = 1e16, 2.9999 # use temporary values to defeat peephole optimizer
HAVE_DOUBLE_ROUNDING = (x + y == 1e16 + 4)There is another useful value in a float.__getformat__ which is hard to find and only documented for internal use:
>>> float.__getformat__('double') 'IEEE, little-endianMaking this information available would make it easier for users to do what we do in test_math:
@requires_IEEE_754 @unittest.skipIf(HAVE_DOUBLE_ROUNDING, "fsum is not exact on machines with double rounding") def testFsum(self): ...
I like the idea to add more informative information,
However, since the type is the structsequence the change can cause the
ValueError: too many values to unpack when the variable is used as a tuple.But the if such use case is not often used, it will be okay
[Dong-hee Na]
However, since the type is the structsequence the
change can cause the ValueError: too many values
to unpack when the variable is used as a tupleStructseq also allows named fields that aren't part of the tuple. That is why I suggested, "consider adding new non-sequence fields ..."
For example, the Posix stat result struct seq has optional fields (
st_blksize, st_blocks, st_rdev, and st_flags) that are available as attributes only.Double rounding is a property of how operations on floats are carried out, rather than being a property of the float format itself; I'm not sure that it belongs in float_info. It's also potentially ill-defined. Right now, as far as I *know*, it seems to be the case that our builds of CPython on x86 or x64 either consistently use x87+extended precision for all floating-point operations, or they consistently use SSE2 for all floating-point operations, but there's no reason that a build couldn't use SSE2 in some cases and x87+extended precision in others. (There are also subtle differences between x87+53-bit precision setting and IEEE 754-following SSE2.)
We also don't have any _reliable_ way to tell whether floats use IEEE 754, though we do have some ad-hoc ways that seem to work in practice (at least for now).
Given that reliable checks aren't possible, it would still be nice (to have flags suchas non_ieee754_detected and double_rounding_detected. If the flag is False it provides no firm guarantees, but it if it is true, it is meaningful.
I agree with Mark, that sys.float_info is not a best place for those additions. Probably it's better to keep such stuff in the Lib/test/support/:
- several test files (3+) now share HAVE_DOUBLE_ROUNDING check, lets move this to Lib/test/support/
float.__getformat__()now can be only "IEEE, big/little" for the CPython. Lets deprecate this semi-private API and move this check to Lib/test/support/. This was implemented by: gh-85989: deprecate float.__getformat__() class method #146400
N.B. see also recent attempt to provide access to the
__STDC_IEC_559__macro.- added a commit that references this issue
on May 28, 2026
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs