Sometimes we add C API (mainly macros) that should be private, but we don't use the _Py prefix. Usually it's due to similar existing names not using the prefix.
During the beta period, let's add _Py to the ones added in 3.15.

My annual scan noticed these:

Header guards:

• Py_CPYTHON_SLICEOBJECT_H in Include/sliceobject.h
• Py_CPYTHON_STRUCTSEQ_H in Include/structseq.h
• Py_SENTINELOBJECT_H in Include/cpython/sentinelobject.h

Configure macros we chose a name for:

• HAVE_EFFICIENT_BUILTIN_SHUFFLEVECTOR
• HAVE_LIBGCC_EH_FRAME_REGISTRATION
• HAVE_PR_SET_VMA_ANON_NAME

And for completeness, configure macros generated by autotools -- these are harder to change:

• HAVE_CLEARENV
• HAVE_PPOLL
• HAVE_STATX
• HAVE_STRUCT_STATX_STX_ATOMIC_WRITE_UNIT_MAX_OPT
• HAVE_STRUCT_STATX_STX_ATOMIC_WRITE_UNIT_MIN
• HAVE_STRUCT_STATX_STX_DIO_MEM_ALIGN
• HAVE_STRUCT_STATX_STX_DIO_READ_OFFSET_ALIGN
• HAVE_STRUCT_STATX_STX_MNT_ID
• HAVE_STRUCT_STATX_STX_SUBVOL
• HAVE_LINUX_CAN_ISOTP_H
• HAVE_DECL_PR_SET_VMA_ANON_NAME

Linked PRs

• gh-149685: Use the _Py prefix for private C macros #149686
• [3.15] gh-149685: Use the _Py prefix for private C macros (GH-149686) #149790