Skip to content

Use _Py prefix for private C API added in 3.15 #149685

@encukou

Description

@encukou

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

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions