Repository navigation
C API: Rename _PyUnstable_GetUnaryIntrinsicName() to PyUnstable_GetUnaryIntrinsicName()? #107149
Description
Activity
I doubt there was a reason for the _. Probably just a habit.
- added 6 commits that reference this issue
on Aug 28, 2023 At the end, all APIs discussed here are public and exposed with the
PyUnstableprefix in the public C API (inInclude/cpython/).Unstable API needs documentation and tests.
Reacted by Erlend E. Aasland2 remaining items
Perhaps #105481 (which added the APIs in question) should be reopened instead.
Ok, I closed this issue and reopened gh-105481 instead.
It's not easy to see on that issue what you mean (which unstable APIs? That issue contained several large PRs that change many things). I think it actually works better to finish it off on this issue or create a new one than to report a large old issue.
Also, PyUnstable_ExecutableKinds was not added in #105481.
Reopening. See #105481 (comment).
- added a commit that references this issue
on Nov 14, 2023 Reopening. See #105481 (comment).
Change implemented by 36aab34. I close again the issue.
Python 3.13 added
_PyUnstable_GetUnaryIntrinsicName()and_PyUnstable_GetBinaryIntrinsicName()to the C API. I don't get the_PyUnstableprefix: PEP 689 – Unstable C API tier usesPyUnstable_prefix.Is it just a typo, or is the API private on purpose? If it's private, why does its name look like as if it's part of the Unstable C API?
cc @brandtbucher @iritkatriel @encukou
Linked PRs