I think it would be better if the field was in uppercase but I don't know if we have many other cases like that.

I think it would be better if the field was in uppercase

This will be inconsistent wrt the rest (other field names are also come from macros).

I'm thinking if it does make sense to mention this flag in cmath docs.

We could say that:

1. Functions selection mostly follows to the Annex G.6 section (modulo conversions and classifications functions). Currently we just mention that functions set is different wrt the math module.
2. Functions behavior follows to the Annex G.6 in exceptional cases (well, with some exceptions, see gh-133895: correct values of cmath.cosh/sinh in case of overflows #135603, which aren't user-visible right now), if sys.float_info.stdc_iec_559 is true.

@picnixz @serhiy-storchaka: What do you think of this change?

I am not sure what is the best place for this constant. What do @mdickinson and @tim-one think about this? Other options are discussed in the issue.

I'm not really comfortable with float_info but I don't really know whether a module-wide constant is better. I would be more comfortable with a new struct, say stdc_info or features_info which contains other feature for the C standard.

I would be more comfortable with a new struct, say stdc_info or features_info which contains other feature for the C standard.

I think, this flag should rather describe conformance with the IEEE 754 / IEC 60559.

@serhiy-storchaka:

I am not sure what is the best place for this constant. What do @mdickinson and @tim-one think about this? Other options are discussed in the issue.

@mdickinson and @tim-one didn't reply. Would you be ok with sys.float_info.iec_60559 flag? IMO it's a good fit.

@serhiy-storchaka, see #145633 (comment).

It looks like the float.__getformat__() class method often misused in the CPython tests. The sys.float_info.iec_60559 flag is a good replacement for this private interface. The sysconfig module doesn't look as a right place to keep this stuff, just because it's dependency on Python implementation (we don't mention somewhere in docs which variables must be available here and how they should be named).

IMO, we only have to decide: where in the sys module put this flag?

Maybe open a DPO thread?

I decided to merge the change adding sys.float_info.iec_60559 attribute. I completed the PR to mention the addition in What's New in Python 3.15.

Since sys.float_info also maps other C float macros, IMO it's a good home to add iec_60559.

Build info on CI runs on this PR:

• Ubuntu x86-64: sys.float_info: sys.float_info(..., iec_60559=True)
• macOS 14: sys.float_info: sys.float_info(..., iec_60559=False)
• Windows x64: sys.float_info: sys.float_info(..., iec_60559=False)
• Emscripten: sys.float_info: sys.float_info(..., iec_60559=False)
• WASI: sys.float_info: sys.float_info(..., iec_60559=False)

So iec_60559 is only true on Ubuntu CI.

Yes, it looks adoption of the standard is poor as before.

@vstinner, maybe it does make sense to revert this pr. Certainly, this flag can't be used for the support.requires_IEEE_754 decorator - it filters out too much.

I also looked at buildbots.

iec_60559=True:

• Debian root: sys.float_info(..., iec_60559=True)
• AMD64 CentOS9 NoGIL 3.x: sys.float_info(..., iec_60559=True)
• ARM Raspbian 3.x: sys.float_info(..., iec_60559=True)
• PPC64LE CentOS9 3.x: sys.float_info(..., iec_60559=True)
• riscv64 Ubuntu23 3.x: sys.float_info(..., iec_60559=True)

iec_60559=False:

• FreeBSD 13: sys.float_info(..., iec_60559=False)
• FreeBSD 14: sys.float_info(..., iec_60559=False)
• FreeBSD 15: sys.float_info(..., iec_60559=False)
• ARM64 MacOS M1 NoGIL 3.x: sys.float_info(..., iec_60559=False)
• SPARCv9 Oracle Solaris 11.4 3.x: sys.float_info(..., iec_60559=False)
• WASM Emscripten 3.x: sys.float_info(..., iec_60559=False)
• wasm32-wasi 3.x: sys.float_info(..., iec_60559=False)

Note: Some buildbots didn't run yet with the new iec_60559 attribute (I restarted the buildbot server this morning, it was stuck for an unknown reason). Some buildbots don't dump test.pythoninfo (ex: Android).

@vstinner, maybe it does make sense to revert this pr.

Why? It remains useful in the platforms where it's true, no?

Certainly, this flag can't be used for the support.requires_IEEE_754 decorator - it filters out too much.

Well, that's another issue.

I built Python with clang 21.1.8 on my Fedora 43 with glibc 2.42-10: sys.float_info(..., iec_60559=True).

That's surprising because https://clang.llvm.org/c_status.html says about "C99 implementation status" that "Clang does not define __STDC_IEC_559__":

Partial
Clang supports much of the language requirements for Annex F, but full conformance is only possible to determine when considering the compiler's language support, the C runtime library's math library support, and the target system's floating-point environment support. Clang does not currently raise an "invalid" floating-point exception on certain conversions, does not raise floating-point exceptions for arithmetic constant expressions, and other corner cases. Note, Clang does not define __STDC_IEC_559__ because the compiler does not fully conform. However, some C standard library implementations ( glibc, musl will define the macro regardless of compiler support unless the compiler defines __GCC_IEC_559, which Clang does not currently define.
Additionally, Clang intentionally will not conform to Annex F on 32-bit x86 without SSE2 due to the behavior of floating-point operations in x87.

/usr/include/stdc-predef.h contains:

/* glibc's intent is to support the IEC 559 math functionality, real
   and complex.  If the GCC (4.9 and later) predefined macros
   specifying compiler intent are available, use them to determine
   whether the overall intent is to support these features; otherwise,
   presume an older compiler has intent to support these features and
   define these macros by default.  */

#ifdef __GCC_IEC_559
# if __GCC_IEC_559 > 0
#  define __STDC_IEC_559__		1
#  define __STDC_IEC_60559_BFP__ 	201404L
# endif
#else
# define __STDC_IEC_559__		1
# define __STDC_IEC_60559_BFP__ 	201404L
#endif

iec_60559=True

That's essentially linux and glibc with "intent is to support" ("An implementation that defines STDC_IEC_559 shall conform to the specifications in this annex." - this is not about best wishes, right?). The rest looks same as 20+ years ago :(, quite disappointing for me.

It remains useful in the platforms where it's true, no?

Yes, at least we can fill bugreports, when it's enabled and things goes wrong.

The cons is that this not useful in the test suite.

I modified Android buildbot to dump also Python build information: sys.float_info(..., iec_60559=False).

And I also modified iOS CI to dump the Python build information: sys.float_info(..., iec_60559=False).

A few more:

• AMD64 Alpine Linux 3.x: sys.float_info(..., iec_60559=True) and platform.libc_ver: musl 1.2.5.
• AMD64 NixOS Unstable 3.x: sys.float_info(..., iec_60559=True) with platform.libc_ver: glibc 2.40
• riscv64 Ubuntu23 3.x: sys.float_info(..., iec_60559=True) with platform.libc_ver: glibc 2.41
• PPC64LE Fedora Stable 3.x: sys.float_info(..., iec_60559=True) with platform.libc_ver: glibc 2.42

So it seems like sys.float_info.iec_60559 is only true (__STDC_IEC_559__ macro is defined) on Linux platforms, using glibc or musl, on many architectures, on any Linux distribution, using GCC or Clang, but not on Android.

It's false on all other platforms: Windows, macOS/iOS, WASI/Emscripten, FreeBSD, Solaris.

I also tested compiler flags on this C program:

#include <stdio.h>

int main()
{
#ifdef __STDC_IEC_559__
    printf("__STDC_IEC_559__ defined\n");
#else
    printf("NO! __STDC_IEC_559__ is NOT defined\n");
#endif
    return 0;
}

• gcc -O3: __STDC_IEC_559__ defined
• gcc -Ofast: NO! __STDC_IEC_559__ is NOT defined
• clang -O3: __STDC_IEC_559__ defined
• clang -O3 -ffast-math: __STDC_IEC_559__ defined

So using GCC (15.2.1), __STDC_IEC_559__ is not defined when using -Ofast, whereas Clang (21.1.8) always defines __STDC_IEC_559__ even if -ffast-math is used.

whereas Clang (21.1.8) always defines STDC_IEC_559 even if -ffast-math is used.

I think it's come from glibc (from quote above):

However, some C standard library implementations ( glibc, musl will define the macro regardless of compiler support unless the compiler defines __GCC_IEC_559, which Clang does not currently define.