I would like to point out that identifiers like “__DYNAMIC_ANNOTATIONS_H__” and “_Py_memory_order” do not fit to the expected naming convention of the C++ language standard.
https://www.securecoding.cert.org/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier

Would you like to adjust your selection for unique names?
* https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Include/dynamic_annotations.h#L56
* https://github.com/python/cpython/blob/130893debfd97c70e3a89d9ba49892f53e6b9d79/Include/internal/pycore_atomic.h#L36

Hi, I'm sorry but I don't understand your problem. Are you trying to build Python using C++? If yes, do you get a compilation error? I'm not sure that it's supported.

Or do you try to build a C extension for Python using a C++ compiler?

See: <https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier>

Basically all names starting with double underscores are reserved for the implementation in C++. Likewise for all names starting with an underscore when defining globals (such as function names).

IIRC C has similar rules for double underscores and for underscore followed by an uppercase letter, but I don't have a handy reference for those.

In general Python's use of these symbols should be safe enough, it is highly unlikely that a C/C++ implementation uses names starting with "_Py" even if those are reserved for the implementation.

@elfring: Do you run into actual problems due to Python's use of these identifiers?

__DYNAMIC_ANNOTATIONS_H__ can be replaced with PY_DYNAMIC_ANNOTATIONS_H.

I don't understand why _Py_memory_order and only _Py_memory_order is a problem. We have tons of symbols starting with _Py: functions, defines, variables, etc.

* How do you think about to reduce the tampering with the reserved name space in mentioned source code (and also in related components)?
* Would you like to avoid that this software depends on undefined behaviour?

(changed the type from "security" because this is not a security incident).

Both ISO C and C++ define "reserved identifiers" that are reserved for the implementation and where use in programs is undefined behaviour. However, these definitions reserve *all* global symbols starting with an underscore, while such symbols are commonly used for private names in libraries. Not just in the Python implementation, but throughout the C/C++ ecosystem. 

Changing both as a large impact on the CPython implementation due to changing identifiers for private symbols, and there is no clear way to pick new names that clearly and concisely indicate that names are private (esp. not without inventing a new convention).  Such a change could also not be done for all released versions of Python (that is, for 3.8 at the earliest), which leads to an increased maintenance cost as well due to a higher chance for merge conflicts when back porting bug fixes. 

Because of this it is IMHO not worthwhile to change the names of private symbols in the CPython implementation unless there is clear evidence that a particular symbol causes problems with compilers.

That said, changing the include guard with double underscores would be fine because that name doesn't follow the regular CPython coding style.

P.S. A draft of an ISO C std: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf. Section 7.1.3 defines what reserved identifiers are.