peps

peps copied to clipboard

It may be unclear to many but C does not specify floating point. I.e. what float and double mean exactly. But Python's floats use double/Float64.

So that means at least one optional C feature is used, Annex F (__STDC_IEC_559__)?

This is sort of a nitpick/question.

But another issue with this PEP is "XP" unexplained. I believe it means "extreme programming", and maybe it's best to link it. Not all may be familiar so maybe it's NOT better to (simply) spell it out.

https://stackoverflow.com/questions/31181897/status-of-stdc-iec-559-with-modern-c-compilers

https://softwarerecs.stackexchange.com/questions/78793/is-there-any-c-compiler-which-defines-both-stdc-and-stdc-iec-559-to-1

https://gcc.gnu.org/onlinedocs/gcc/Floating-point-implementation.html

The accuracy of the floating-point operations and of the library functions in <math.h> and <complex.h> that return floating-point results (C90, C99 and C11 5.2.4.2.2). The accuracy is unknown.

---

📚 Documentation preview 📚: https://pep-previews--3593.org.readthedocs.build/

The following commit authors need to sign the Contributor License Agreement:

• [email protected]

Click the button to sign:

I feel that the addition, as proposed, does not make the PEP clearer for most people. And IEEE floating point is what’s provided by all supported platforms.

I think at least https://en.wikipedia.org/wiki/Extreme_programming or other link for XP could be added.

I know you can by now expect IEEE floating point, and in all C compilers. Maybe write "C11 with IEEE floating-point, and otherwise no optional features"?

I forget does Python use 64-bit floats on all platforms, or 80-bit (registers) on x86 (with 64-bit for storage format)?

Would it be better to list the optional features? Or remove the note entirely, and leave the necessary standards extensions unspecified?

In addition to the Annex F floats, CPython 3.13 now also needs C11 atomics (or MSVC).

@encukou, Is Annex F is required? Up to date build requirements says: "A C11 compiler. Optional C11 features are not required. [...] Support for IEEE 754 floating-point numbers and floating-point Not-a-Number (NaN)."

Strictly speaking, this is a requirement for the platform, i.e. to binary format for doubles, not to arithmetic, for example. And I'm not sure that configure script will fail, if neither DOUBLE_IS_* macro defined. CC @vstinner.

C17 says: "An implementation that defines __STDC_IEC_559__ shall conform to the specifications in this annex." And:

sk@note:~/src/cpython $ git grep __STDC_IEC_559__ || echo "I've had worse."
I've had worse.

Edit, for context:

• https://mail.python.org/archives/list/[email protected]/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/
• https://github.com/python/cpython/issues/91073

Yeah, “floating-point numbers” is a bit vague -- AFAIK, we require some things (a NaN, infinities); for some we probably have tests but the language won't break if you ignore failures (like arithmetic behaviour); but don't need everything from the annex. #ifdef __STDC_IEC_559__ would check for strict compliance; rather than checking that we'll fail on individual pieces that are missing.

So, yeah, best left as a platform requtrement rather than a C standard requirement.

This is sort of a nitpick/question.

But practically: we only test a handful of platforms (see PEP 11). If you have a platform/compiler where Python doesn't compile, we can take (small) patches but can't guarantee they'll continue working.

---

I'll close this issue; if you want more discussion it's better to have it on Discourse.