Right, they prioritise compatibility for their users. So do I (possibly related, no doubt some ideals have rubbed off on me in the last decade ), which is why I would rather see us change what we want to ensure compatibility, rather than simply telling others to get with the times.
As I’ve pointed out on the bug, this is already a compatibility break that we’re avoiding discussing specifically in this thread. So arguably, changing the minimum language version for users is no more of a break. Though if the scale of breakage goes from “weird reference counting when you mix ABI3 modules with 3.12 modules” to “all users have to change language version to compile with Python”, then it probably deserves to go back to the steering council to reevaluate whether that amount of breakage is small enough for us to slip in without warnings or deprecation cycles.
Worth factoring in that I doubt any of the build backends that exist either default to a particular C or C++ standard, or offer convenient options to do so. At least on Windows (not sure about other platforms), these options don’t flow through sysconfig in any way. But the counter to that is that neither do warning options, so it’s likely that anyone who will notice the break is already in a position where they’ve done some configuration (i.e. every single extension module that devs on Linux and uses CI on Windows won’t actually have to go figure it out).
“No compiler warnings in system compilers for tier 1 platforms based on our build settings. For public header files included in an otherwise empty source file, there should be no compiler warnings at any default, reasonable and/or recommended settings, including -W4 (but not -Wall), -pedantic, enabling C++ mode or disabling proprietary extensions.”
Possibly, yeah. I think the underlying issue is that enabling “standards” mode disables “quirks” mode, which is not backwards compatible, and so the compiler is doing the right thing by warning that in its current mode (C89, presumably), it’s a nonstandard extension.
The more relevant argument is how long until the standards mode becomes the default, but I suspect the answer is that it will remain opt in, given the incredibly long tail of compatibility they want to protect. If we got setuptools and meson, etc. to activate it by default for extensions, we’d be able to get there sooner, though personally I’d recommend that sort of change gets a normal deprecation/warning cycle.
IMO the Python C API should try to remain compatible with the oldest C standard in strict mode. Any new C shiny feature is causing troubles with uncommon compilers on some platforms. It can lead to compiler warnings or miscompiled code in the worst case.
There are two victims of the usage of new C shiny features in the public C API: other Python implementation fighting to be as compatible as possible with CPython (but having different memory layout, different GC)… and CPython itself! More regular simple C code ease changes of CPython in my experience.
I know that many disagree, but this issue is just another example that the C API leaks too many implementation details: structures layout and members, and inlined code. Opaque structure and opaque function calls would simply avoid these issues: it would be very basic C function declaration (C89), no fancy C feature, no compiler warning or error, no long discussion about C standard, strict C, etc.
), which is why I would rather see us change what we want to ensure compatibility, rather than simply telling others to get with the times.