René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[C API] Meta issue: add new public functions with doc+tests to replace removed private functions","articleBody":"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](https://discuss.python.org/t/c-api-my-plan-to-clarify-private-vs-public-functions-in-python-3-13/30131).\r\n\r\nI 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.\r\n\r\nTo make a function public, we should:\r\n\r\n* Follow new C API guidelines to avoid past design mistakes:\r\n\r\n  * https://devguide.python.org/developer-workflow/c-api/\r\n  * [PEP 733: An Evaluation of Python's Public C API](https://github.com/python/peps/pull/3491) (it's currently a draft)\r\n  * https://github.com/capi-workgroup/api-evolution/issues\r\n  * This part is still a work-in-progress, but there is an agreement on some common good practice, like don't return borrowed references, and design the API so the caller doesn't have to check for exception by calling PyErr_Occurred().\r\n\r\n* Document the API.\r\n* 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.\r\n\r\nI 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).\r\n\r\nThis 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.\r\n\r\nThe target is to make most C extensions compatible with Python 3.13 when Python 3.13 beta1 is released. Obviously, sooner the better.\r\n\r\n---\r\n\r\nC 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?","author":{"url":"https://github.com/vstinner","@type":"Person","name":"vstinner"},"datePublished":"2023-10-30T08:28:37.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":15},"url":"https://github.com/111481/cpython/issues/111481"}