Ronald Oussoren <ronaldousso...@mac.com> added the comment:
(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. ---------- type: security -> enhancement _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35671> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
