Most of this is already in PEP-7. IMO we should move guidelines with user-visible effects out of the style guide.
For new API, all public names must be prefixed with Py.
Names that users should not use directly, but should be visible to the compiler/linker, should be prefixed with _Py.
This applies to all names in a global namespace: functions, macros, variables, typedefs, structs, enums, etc.; not to parameters or struct fields.
(XXX: In C, “all identifiers that begin [...] with an underscore (_) followed by an uppercase letter are reserved for any use”. Using the _Py prefix has undefined behavior.)
The Py_ prefix is reserved for global service routines like Py_FatalError; specific groups of APIs use a longer prefix, e.g. PyString_ for string functions.
The prefix is in mixed case, even in macro names (e.g. PyString_AS_STRING).
Unstable API is prefixed with PyUnstable_ instead of Py, e.g. PyUnstable_Long_IsCompact or *PyUnstable_String_GET_SIZE.
Most of this is already in PEP-7. IMO we should move guidelines with user-visible effects out of the style guide.
For new API, all public names must be prefixed with
Py.Names that users should not use directly, but should be visible to the compiler/linker, should be prefixed with
_Py.This applies to all names in a global namespace: functions, macros, variables, typedefs, structs, enums, etc.; not to parameters or struct fields.
(XXX: In C, “all identifiers that begin [...] with an underscore (_) followed by an uppercase letter are reserved for any use”. Using the
_Pyprefix has undefined behavior.)The
Py_prefix is reserved for global service routines likePy_FatalError; specific groups of APIs use a longer prefix, e.g.PyString_for string functions.The prefix is in mixed case, even in macro names (e.g.
PyString_AS_STRING).Unstable API is prefixed with
PyUnstable_instead ofPy, e.g.PyUnstable_Long_IsCompactor *PyUnstable_String_GET_SIZE.