You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
C API: Remove private functions from abstract.h #106084
Over the years, we accumulated many private functions as part of the public C API in abstract.h header file. I propose to remove them: move them to the internal C API.
Can we keep _PyObject_Vectorcall and such?
The underscore served the same purpose as today's unstable API, and so i think we should follow that process:
The old name should remain available until the new public name is deprecated or removed. There’s no need to deprecate the old name (it was unstable to begin with), but there’s also no need to break working code just because some function is now ready for a wider audience.
The #define is not a big maintenance burden, and there's no reason to punish early adopters or people who want easier compatibility with 3.8.
Other Python implementations have to implement it just because some C extensions use them: not all Python implementations can implement aliases with #define.
Macros are not available in C extensions which don't use the header file but use directly symbols: macros are bad, see https://peps.python.org/pep-0670/
A minority of project still refer to these old aliases. A code search on PyPI top 5,000 projects find matches in 8 projects:
Oh, let's remove the docs!
I don't think we need to test simple aliases.
Other Python implementations have to implement it just because some C extensions use them: not all Python implementations can implement aliases with #define.
That's OK, IMO.
If the implementation is close to CPython, it needs to do much weirder things.
If it's not that close, and users typically need some porting to use it, the users need to remove the underscore.
Macros are not available in C extensions which don't use the header file but use directly symbols: macros are bad, see https://peps.python.org/pep-0670/
Yes, you shouldn't use them and sometimes you can't. That doesn't apply to code that's already using them.
Names prefixed by an underscore, such as _Py_InternalState, are private API that can change without notice even in patch releases. If you need to use this API, consider reaching out to CPython developers to discuss adding public API for your use case.
I don't see why these aliases would be treated differently.
By the way, in this case, there is already a public API for these private functions. So migrating code is trivial.
I don't see why these aliases would be treated differently.
Because the API was added before that note was added to the docs. Those who used the API might not have seen the note, and it is unfair of us to change the rules later.
If users read the docs now they should follow it, and it's not useful to add legacy considerations to user-facing docs. But core devs should follow the devguide and PEPs, and be conservative if there's any doubt.
Activity
pythongh-106084: Remove old PyObject call aliases
pythongh-106084: Remove old PyObject call aliases
pythongh-106084: Remove old PyObject call aliases
pythongh-106084: Remove _PySequence_BytesToCharpArray() function
pythongh-106084: Remove _PySequence_BytesToCharpArray() function
pythongh-106084: Remove _PySequence_BytesToCharpArray() function
gh-106084: Remove old PyObject call aliases (#106085)
gh-106084: Remove _PySequence_BytesToCharpArray() function (#106088)
pythongh-106084: Remove _PyObject_HasLen() function
gh-106084: Remove _PyObject_HasLen() function (#106103)
pythongh-106084: Remove _PyObject_RealIsInstance() function
gh-106084: Remove _PyObject_RealIsInstance() function (#106106)
pythongh-106084: Remove _PyObject_CallMethod() function
pythongh-106084: Remove _PyObject_CallMethod() function
pythongh-106084: Remove _PyObject_CallMethod() function
gh-106084: Remove _PyObject_CallMethod() function (#106159)
encukou commentedon Jun 30, 2023
Can we keep
_PyObject_Vectorcalland such?The underscore served the same purpose as today's unstable API, and so i think we should follow that process:
The
#defineis not a big maintenance burden, and there's no reason to punish early adopters or people who want easier compatibility with 3.8.vstinner commentedon Jun 30, 2023
I would like to reduce the size of the C API. Aliases are causing a maintenance burden:
#define.A minority of project still refer to these old aliases. A code search on PyPI top 5,000 projects find matches in 8 projects:
Fixing these projects is easy: it's just about removing an underscore prefix.
encukou commentedon Jun 30, 2023
in this case, it's obvious.
Oh, let's remove the docs!
I don't think we need to test simple aliases.
That's OK, IMO.
If the implementation is close to CPython, it needs to do much weirder things.
If it's not that close, and users typically need some porting to use it, the users need to remove the underscore.
Yes, you shouldn't use them and sometimes you can't. That doesn't apply to code that's already using them.
vstinner commentedon Jul 1, 2023
Just a reminder from the C API doc:
I don't see why these aliases would be treated differently.
By the way, in this case, there is already a public API for these private functions. So migrating code is trivial.
encukou commentedon Jul 3, 2023
Because the API was added before that note was added to the docs. Those who used the API might not have seen the note, and it is unfair of us to change the rules later.
If users read the docs now they should follow it, and it's not useful to add legacy considerations to user-facing docs. But core devs should follow the devguide and PEPs, and be conservative if there's any doubt.
vstinner commentedon Jul 22, 2023
I close this issue to continue the discussion in the more complete issue #106320.