Hello,
Currently, PEP 7 mandates the mixed-case Py (or _Py) prefix for preprocessor macros. That looks weird to some people, and we do have existing macros that use the uppercase PY instead.
Serhyi suggested we could use PY for macros that are safe to evaluate in the preprocessor (i.e. in an #if or #ifdef).
I’d like that convention. It adds a useful hint: the macro isn’t just usable in #iftoday, but we also intend to keep it that way.
As with any convention, there’s value in only using it for new API, even if existing macros don’t always follow it.
There are a few PY* macros that aren’t #if-safe, but they seem easy to update (like PY_VECTORCALL_ARGUMENTS_OFFSET) or unlikely to matter (like PYTHREAD_INVALID_THREAD_ID).
There’s a lot more Py* macros that are intended for #if, like Py_DEBUG or Py_GIL_DISABLED. There’s not much harm in leaving them as-is; but I expect we’d add a few PY* aliases to help linters [1]. Adding a macro alias, and keeping the old spelling, is rather cheap.
I’m equally split between “safe/intended for preprocessor” or “represents a constant value/enum” (as opposed to a preprocessor boolean). I suspect we may have tended more towards the latter in the past? But I haven’t done a survey to check.
As an example, SIZEOF_SIZE_T can be used in preprocessor expressions. This is the reason why it is defined as a literal constant instead of simply sizeof(size_t) (and the same is true for other SIZEOF_, *_MAX, and *_MIN macros). But PYTHREAD_INVALID_THREAD_ID, defined as ((unsigned long)-1), – cannot, because the preprocessor knows nothing about C types.
The ALL_CAPS convention for macros is more common in the world, Python’s habit to use the Py_ prefix for macros is rather an exception. I think this explains why we have so much macros with the PY_ prefix – they all are errors. But instead of simply fixing these errors or ignoring them, we could regulate the use of the PY_ prefix. It may already be too later, becuase there are many inconsistenciies in existing names.
