In a follow-up to #86,

I propose formally soft-deprecating helper macros which have equivalents in C99.
We won't be updating them, and we won't be using them as precedent for adding similar macros.
I propose undefining them internally (with Py_BUILD_CORE), and switch away if we still use them.

• Py_LL & Py_ULL: Use LL/ULL suffixes.
• Py_MEMCPY (already soft-deprecated)
• Py_VA_COPY: Use va_copy directly.
• PY_LONG_LONG, PY_LLONG_MIN, PY_LLONG_MAX, PY_ULLONG_MAX, PY_INT32_T, PY_UINT32_T, PY_INT64_T, PY_UINT64_T, PY_SIZE_MAX: Use C99 types/limits
• Py_UNICODE_SIZE: Use sizeof(wchar_t) directly
• PY_FORMAT_SIZE_T: Use "z" directly
• Py_BUILD_ASSERT: Use _Static_assert (C11) or static_assert (C++ & C23) instead
• Py_ALIGNED: Use _Alignas (C11) or alignas (C++ & C23) instead.
  • This one should be undefined internally (with Py_BUILD_CORE); we should switch to the more robust _Py_ALIGNED_DEF instead.

Additionally I propose soft-deprecating the following:

• Py_BUILD_ASSERT_EXPR: In virtually all cases, Py_BUILD_ASSERT is enough.
  In CPython it's only used to define Py_BUILD_ASSERT (for old compilers) and Py_ARRAY_LENGTH (which can do without it).
• PY_DWORD_MAX: Not a good precedent for public API. CPython internals should continue using it.

For Py_UNICODE_WIDE, which is scheduled for removal, I propose soft-deprecating instead. There's been no visible warning outside docs, and removing an #ifdef macro is indistinguishable from making it “false”.

I consider this clerical clean-up so I haven't started a wider discussion. Let me know if you think any of this is controversial.

• @encukou
• @erlend-aasland
• @serhiy-storchaka
• @vstinner
• @zooba