Ah I'm sorry I put this one as ready for review but I learned that _ + capital letter was also UB (#128248 (comment)) so I'll fix them tomorrow.

It's not exactly UB, it's just that those names are reserved for the C standard. In practice, it's probably fine to leave it, and not worth the inconsistency/confusion of adding a _Py prefix to everything.

The problem with _Py would remain. It seems to be UB with _ + capital letter. So I followed @encukou's advice.

Half the codebase is UB then! I understand the issue, but what's the actual chance that we'll get broken by prefixing something with _Py? Or with _ClassName_CAST?

The chance is probably almost zero but Petr wanted to avoid adding more UBs. So I guess it makes sense. By the way, I found it easier to actually type the macro without the leading underscore as well so it's also a good idea to actually ease writing!

Half the codebase is UB then!

Half?
Most of the codebase technically has UB.

It's not exactly UB, it's just that those names are reserved for the C standard.

It is exactly UB. That's a hard fact. The C23 standard says:

• “All identifiers that begin with a double underscore (__) or begin with an underscore (_) followed by an uppercase letter are reserved for any use, except those identifiers which are lexically identical to keywords.”
• “All identifiers that begin with an underscore are reserved for use as identifiers with file scope in both the ordinary and tag name spaces.”
• “If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), the behavior is undefined.”

The chance is probably almost zero

Also yes. CPython is big enough that we can hope that compiler/libc authors won't actually use the _Py prefix, or underscore+lowercase, for naming new features. The disruption wouldn't be worth it, we hope.
The fact remains that CPython is doing the wrong thing here, and relying on the compiler/libc to be lenient.

In practice, new features in C nowadays tend to start with double-underscore or underscore+uppercase. Let's not use more of those -- especially in PRs that remove UB.

(Speaking of technicalities: PEP-7 says “#undef file local macros after use”. I think it's OK to ignore that for macros that would go in a header, if there was a header for the module. But it's always good to know the rules one is breaking :)

Concerning the #undef, I can address that in a separate issue (I don't mind doing mechanical tasks like these, especially if this kind of task can be automated; the task of fixing UB is much more harder though). We can also fix this kind of issue by using a static inline function but since I started using macros instead for the.. 50 previous PRs, I think it's ok to keep a macro in a .c file (and not undef it if it has small chance to being included from a header)

It is exactly UB. That's a hard fact. The C23 standard says:

Not disagreeing, I'm just saying it's not UB in the same way that using uninitialized memory is UB. I'm just pointing out that messing around with it probably isn't worth the weird inconsistencies in our macros. There's no actual plan to remove _ from the codebase, right?