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.

Lets try to make some progress here.

I am not sure what is the best place for this constant. Other options are discussed in the issue.

@serhiy-storchaka, other options so far:

1. sysconfig
2. some flag in sys.stdc_info or sys.features_info, which contains other features for the C standard.
3. some flag in the sys module namespace.

(1) or (2) don't make any sense, as the flag is not C-specific at all. So, (3) is only option. But the sys namespace is already big. And the new flag logically fits float_info: it offers some additional information about float type.

Maybe we should rename this flag to sys.float_info.iec_60559?

Other fields in this named tuple also have no strict binding to the C standard. Floating-point numbers in C are defined by same model as in the IEC 60559, i.e. have radix ($b$), precision ($p$), emax ($e_{\rm max}$) and emin ($e_{\rm min}$) parameters. Everything else can be expressed via such parameters, e.g. min_10_exp is just $\lceil\log_{10}b^{e_{\rm min}-1}\rceil$. In other words, references to C macros might be convenient here, but these field are actually language-agnostic and do make sense e.g. for the RustPython. Maybe it's better to avoid mentioning the C standard here?

Maybe we should rename this flag to sys.float_info.iec_60559?

I still support this option (sys.float_info).