GeezerVison is showing github.com — Undocumented 3.14 C API · Issue #135755 · python/cpython
Undocumented 3.14 C API #135755DescriptionThe following public C API is new in 3.14 (beta 3 & 4, relative to 3.13.0), and as of this writing it looks either:
- undocumented,
- documented incorrectly, or
- public by mistake.
previously: 3.13
next: 3.15
"PYOS" (#135928):
-
PYOS_LOG2_STACK_MARGIN: Include/pythonrun.h
-
PYOS_STACK_MARGIN_BYTES: Include/pythonrun.h
-
PYOS_STACK_MARGIN_SHIFT: Include/pythonrun.h
"SPECIAL" (#135922):
-
SPECIAL_MAX: Include/ceval.h
-
SPECIAL___AENTER__: Include/ceval.h
-
SPECIAL___AEXIT__: Include/ceval.h
-
SPECIAL___ENTER__: Include/ceval.h
-
SPECIAL___EXIT__: Include/ceval.h
Header guards (traditionally named Py_*_H, but a leading underscore would be better for new ones) (#135921):
-
Py_AUDIT_H: Include/audit.h
-
Py_CPYTHON_AUDIT_H: Include/audit.h
-
Py_REFCOUNT_H: Include/refcount.h
New configure constants.
(IMO, if we don't want users to touch these, they should use the _Py prefix.
If we do want users to use them, they need docs.)
New HAVE configure constants -- a lost cause:
-
HAVE_BACKTRACE
-
HAVE_DECL_UT_NAMESIZE
-
HAVE_DLADDR
-
HAVE_DLADDR1
-
HAVE_EXECINFO_H
-
HAVE_GETLOGIN_R
-
HAVE_LINK_H
-
HAVE_LINUX_NETFILTER_IPV4_H
-
HAVE_LINUX_SCHED_H
-
HAVE_PTHREAD_GETATTR_NP
-
HAVE_PTHREAD_GETNAME_NP
-
HAVE_PTHREAD_SETNAME_NP
-
HAVE_SYS_PIDFD_H3
-
HAVE_TTYNAME_R
-
HAVE_USABLE_WCHAR_T
-
HAVE_UT_NAMESIZE
New CO_ flags (documented in inspect; Sphinx sees none of these as C macros): (#135980)
-
CO_HAS_DOCSTRING: Include/cpython/code.h:115
-
CO_METHOD: Include/cpython/code.h:115
Linked PRs
- Check links above! I prefer attaching doc fixes & renames to issues that added the API.
ActivityZeroIntensity commented on Jun 20, 2025 For PyFunction_GET_BUILTINS, I don't think we document any existing PyFunction_GET_* functions. I'm happy to take on documenting all those if you haven't started with it. picnixz commented on Jun 20, 2025 I'll take care of adding the PY_* to HACL ones, though the HACL ones are actually because of mismatches. I actually don't remember why we have those mismatches in the first place... encukou commented on Jun 23, 2025 Thank you, go ahead!
I'd prefer if the people involved in adding them are also involved in the documentation -- it's no always easy to guess the intent :) sergey-miryanov commented on Jun 23, 2025 Should Py_TPFLAGS_PREHEADER (Include/object.h) also be documented? encukou commented on Jun 23, 2025 sergey-miryanov commented on Jun 23, 2025 @encukou I can't reopen #95245 because I haven't rights :) So I added and linked PR to this issue. AA-Turner commented on Jun 24, 2025 Reacted by Sergey Miryanov Fidget-Spinner commented on Sep 1, 2025 Should Py_TAIL_CALL_INTERP be made private as well? vstinner commented on Sep 1, 2025
Should Py_TAIL_CALL_INTERP be made private as well?
Unless there is a clear usage for it in 3rd party code, I would also suggest to make it private. Fidget-Spinner commented on Sep 1, 2025
Should Py_TAIL_CALL_INTERP be made private as well?
Unless there is a clear usage for it in 3rd party code, I would also suggest to make it private.
Ok I think this should be made private then. Unfortunately, I'm not sure how to do it. Do I just add an underscore in front? vstinner commented on Sep 1, 2025
Ok I think this should be made private then. Unfortunately, I'm not sure how to do it. Do I just add an underscore in front?
Yes, just add an underscore prefix. Fidget-Spinner commented on Sep 16, 2025 @vstinner or @encukou I have not made the symbol private yet. If you want someone to sprint on it this week, I'm happy to review the PR, but this isn't on top of my priority list so I'm not gonna get to it anytime soon. vstinner commented on Sep 16, 2025 encukou commented on May 11, 2026 For the record, for 3.15 the same scan only found API that shouldn't be documented: #149685
Thanks @ZeroIntensity for adding the CI check in #142102!
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|