Skip to content

PEP 7: Reword & split the "C dialect" section #4557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
+27 −11
Open

PEP 7: Reword & split the "C dialect" section #4557

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
551479f
PEP 7: Reword & split the "C dialect" section
encukou Aug 20, 2025
866f500
"more restrictive"
encukou Aug 21, 2025
a40584d
Use proper ReST link syntax
encukou Aug 22, 2025
2f1726e
Add examples of wrappers; make not explicitly for users
encukou Aug 25, 2025
24532dd
Update peps/pep-0007.rst
encukou Aug 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 27 additions & 11 deletions peps/pep-0007.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,12 +26,24 @@ particular rule:
clean up someone else's mess (in true XP style).


C dialect
=========
.. _c_dialect:

C standards
===========

Follow the following standards.
For features that aren't in the relevant standard, use CPython-specific
wrappers (for example: ``_Py_atomic_store_int32``, ``Py_ALWAYS_INLINE``,
``Py_ARITHMETIC_RIGHT_SHIFT``; ``_Py_ALIGNED_DEF`` in public headers).
When adding such wrappers, try to make them easy to adjust for unsupported
compilers.

* Python 3.11 and newer versions use C11 without `optional features
<https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features>`_.
The public C API should be compatible with C++.
<https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Optional_features>`__.
The public C API should be compatible with C99 and C++.

(As a reminder to any users reading this: this PEP is a *style guide*; these
rules are there to be broken.)

* Python 3.6 to 3.10 use C89 with several select C99 features:

Expand All @@ -44,15 +56,19 @@ C dialect
- C++-style line comments

* Python versions before 3.6 used ANSI/ISO standard C (the 1989 version
of the standard). This meant (amongst many other things) that all
declarations must be at the top of a block (not necessarily at the
top of function).
of the standard). This meant, amongst many other things, that all
declarations were at the top of a block.


Common C code conventions
=========================
Comment on lines +63 to +64
Copy link
Member

@AA-Turner AA-Turner Aug 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any alliteration appropriate? Always, and all allotted alliteration allowance assured as apportioned! All adults are alliteration acclimatised as affably attested, accidental amelioration & aggravation apart. Avid alliterators adept at alliteration advance: abruptly, audaciously, ambitiously, and admirably!

Ahoy!

A


* Don't use compiler-specific extensions, such as those of GCC or MSVC
(e.g. don't write multi-line strings without trailing backslashes).
* Don't use compiler-specific extensions, such as those of GCC or MSVC.
For example, don't write multi-line strings without trailing backslashes.

* All function declarations and definitions must use full prototypes
(i.e. specify the types of all arguments).
* All function declarations and definitions must use full prototypes.
That is, specify the types of all arguments and use ``(void)`` to declare
functions with no arguments.

* No compiler warnings with major compilers (gcc, VC++, a few others).

Expand Down