-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[C API] Meta issue: add new public functions with doc+tests to replace removed private functions #111481
Comments
Issues asking to add public APIs for removed private APIs. DONE:
Private API restored: Rejected:
Note: I update this comment time to time. |
See also discussion: Is Python 3.13 going to be Python 4?. |
Guido said in #106320 (comment):
Can we get consensus on that -- that is, revert the removal for these? Or should we get a SC decision? |
My plan mentioned at the beginning of this issue is to add public functions asked by users. And if we run out of time before beta1, start to revert and consider adding more public functions later. Alpha 1 was just released a few days ago. Can we start by adding public functions for now, and only move to the "revert" backup plan later if needed? Beta 1 is scheduled in May 2024: in 6 months. Usually it takes several months to get more C extensions compatible with the new Python versions. I'm surprised that for Python 3.13, people want suddenly to get "everything" compatible at day 1 of the alpha1 release. Isn't it not a little bit early to expect that? |
I'd much prefer 'revert' for any API anyone is found using in 3.13. We need to treat 3.13 as a more special than usual release and aim to minimize compatibility headaches for existing project code. That way more things that build and run on 3.12 build can run on 3.13 as is or with minimal work. This will enable ecosystem code owners to focus on the bigger picture task of enabling existing code to be built and tested on an experimental pep703 free-threading build rather than having a pile of unrelated cleanup trivia blocking that. |
I talked to Victor privately, and confirmed that we fundamentally disagree with each other. Victor believes that the plan (https://discuss.python.org/t/30131) has overwhelming support and no significant opposition, and it doesn't need a PEP. |
This issue is about adding public functions for removed private functions. Would you mind to open a new issue to discuss revert? Otherwise it's unclear what is the scope of this issue. Or are you saying that we must not add public functions, but stick to private functions forever? |
I propose to revert Python 3.13 C API incompatible changes causing most troubles right now. |
See also issue gh-112026: [C API] Revert of private functions removed in Python 3.13 causing most problems. |
Indirectly related: Python 3.13 removed deprecated functions to configure the Python initialization, such as Py_SetPath(). The replacement API PyConfig is excluded from the limited C API. I'm working on a replacement for the stable ABI: Add PyInitConfig C API. |
List of removed C functions reverted in Python 3.13 alpha2: #112026 (comment) |
This is used in pywin32, and the function being moved to internal headers broke with 3.13. Restore it for now to eventually be considered for being made a public symbol. See also pythongh-112026 (previous restoration) and pythongh-111481 (public replacements)
|
|
Pyodide issue: capi-workgroup/problems#79 |
All known issues have been fixed, I close this issue. The work can continue in new issues. |
Many private functions were removed in issue #106320. My plan is to add public functions for removed private functions which are used by 3rd party extensions: see C API: My plan to clarify private vs public functions in Python 3.13.
I don't think that the fact that a private function was used must always justify to directly expose the exact same API to the public C API. Usually, private functions expose implementation details, use weaker or not check such as checking argument types, are not documented, and are not tested.
To make a function public, we should:
Follow new C API guidelines to avoid past design mistakes:
Document the API.
Write some basic unit tests (for non regression). The bare minimum is to make sure that the constant exists and call each function at least once.
I also would like to add new public functions to https://pythoncapi-compat.readthedocs.io/ to provide them to Python 3.12 and older (by calling the old private functions).
This work will take time. Depending on how it goes, we should consider reverting some removals if there is too much pressure, to unblock some critical dependencies.
The target is to make most C extensions compatible with Python 3.13 when Python 3.13 beta1 is released. Obviously, sooner the better.
C extensions which want to access implementation details can use the internal C API. By default, I modified the internal functions to no longer export internal functions, only make them usable by Python internals: they cannot be used by shared libraries such as stdlib C extensions. This part is unclear to me. Should we expose more internal functions. Which ones? How do you decide if a function should be exported or not?
The text was updated successfully, but these errors were encountered: