Previous requests:

• Python 3.12:

  • Python 3.12.2 headers contain non-C90-compliant code cpython#116869
  • python/cpython@a9c304c
  • https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057442 -- project: onboard

• Python 3.11:

  • Python 3.11 C API is not compatible with ISO C90: ISO C90 forbids mixed declarations and code cpython#92781 -- project: PostgreSQL
  • python/cpython@90e7230
  • https://bugzilla.redhat.com/show_bug.cgi?id=2084008#c0 -- project: xen

Building Python requires a C11 compiler, but the C API should try to remain as usable as possible: support C99 and partially ISO C90. The C API is no longer strictly compatible with ISO C90, since it uses C99 // comment style.

There are still a few projects using the Python C API or embedding Python which are built with -Werror=declaration-after-statement compiler flag. I suppose that the flag was used 5-10 years ago to catch build errors in advance since MSVC didn't support C99. Today, MSVC supports C11 and so this flag may no longer be relevant. Well, it's cheaper to change 2 lines in the C API per year, rather than arguing if -Werror=declaration-after-statement is strictly required or not.

Before, this rule was unwritten. I propose to write it down.

cc @serhiy-storchaka @colesbury @erlend-aasland

See also python/cpython#116990 which implements this check on the C API test suite.

What? Why? Where is the discussion?

What? Why? Where is the discussion?

The discussion is here. Should it happen somewhere else?

I feel there needs to be a more public discussion of whether we really need to cramp our style to support some projects that still use a 30-year-old C dialect. Pointing to a few closed issues does not form a discussion IMO.

This is not an endorsement of the requirement, but a clarification -- I had originally read it as a requirement that we build something with C90. I also clarify that this only affects inline functions in public headers.

Sorry, my sentence was misleading. Your sentence is way better :-)

The rule is also useless unless there's a CI build action that points out violations of this rule.

As written previously, I just added test_cext which implements this check (I wrote it for other checks).

If we change this "unwritten" rule, I can just remove the CI check, but it might be good to have such check in 3.11 and 3.12 branches to not change the "status quo" of stable versions. Moreover, 3.12 was already fixed (it was just 2 lines).

So what would need to be changed in main? Do you have a draft PR?

This would have been easier if you had obtained consensus elsewhere instead of just in your own head. :-)

So what would need to be changed in main?

There is no further changes planned. This change only proposes to require fixing future issues with -Werror=declaration-after-statement.

I looked further in history to try to identify the number of impacted projects.

• 2020

  • python/cpython@faf626b
  • cpython/abstract.h not compatible with C90 cpython#83796
  • bpo-39615: Make cpython/abstract.h compatible with C90 cpython#18481

• 2017

  • python/cpython@f7eda38
  • Fix the only non-C90 comment to be C90 compatible. cpython#566

But none of these changes mention any project name, only "third-party code".

In short, I only found 3 projects: PostgreSQL, Xen and onboard.

I think the best explanation can be found in this comment in 2022 by @petere (emphasis in mine):

PostgreSQL is another package that uses -Wdeclaration-after-statement and as a consequence occasionally runs afoul of Python header files. As you say, it's not a technical requirement but more a desire to maintain a consistent style from the before-C99 days. Maybe this is a battle we (PostgreSQL) will lose some day, but in the meantime, poking the Python devs once a year is less work then re-litigating the code style choice among the PostgreSQL devs. ;-)

@serhiy-storchaka: Do you want to continue this tradition to stay compatible with -Werror=declaration-after-statement? I'm asking you, since you approved most changes to fix issues with this flag.

Is it worth it? For a product as big as PostgreSQL, it can be hard to change their policy. On the Python side, it's usually about changing 2 lines per year.

PostgreSQL, xen, and Linux already changed their code. They no longer compile Python.h with -Werror=declaration-after-statement

• postgres/postgres@58c3151
• xen-project/xen@40be630
• torvalds/linux@a7789d3

Honestly, if Linux, PostgreSQL and Xen stopped using the flag, I don't think that we should still care about it. It becomes more and more annoying since the Python C API has more and more static inline functions.

So I wrote PR #3734 to write down that we supported this flag, but we stop supporting it. I'm not sure if it's worth it to mention it explicitly.

I close this issue.