On 20.06.2022 17:37, Victor Stinner wrote:
[...] This will benefit both core devs and extension writers, since only a healthy and reasonably complete Python C API will help sustain the popularity and attractiveness of Python in areas which are far away from core development - e.g. most of the PyData or scientific space.
I'm not sure what do you propose in practice?
The idea is that instead of declaring a "don't use" policy, as Petr suggested, we keep the "use at your own risk" policy and add a note suggesting to open a ticket "Please create a public version of the _Py_XYZ API" (because of missing functionality in the public API), whenever making use of a private API.
That way we get in touch with people who need internal APIs exposed in the public API and can hash out the details more easily.
The code search approach, several core devs are using, is helpful as well, but the direct interaction on a ticket gives you better feedback on the reasons why internal APIs were used.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 20 2022)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/