On 31. 01. 22 15:40, Victor Stinner wrote:
On Mon, Jan 31, 2022 at 1:48 PM Petr Viktorin firstname.lastname@example.org wrote:
(* we could also break the stable ABI, and we could even do it reasonably safely over a long period of time, but that's a whole different discussion.)
IMO the stable ABI must be change in the long term, it still leaks too many implementation details. But right now, I didn't gather enough data about the problematic APIs and what must be changed exactly. I would prefer to only do once the work will be really blocked and there would be no other choice.
Right now, I'm focused on fixing the *API*. It doesn't require to break the stable ABI.
If we change the stable ABI, I would prefer to fix multiple issues at once. Examples:
- No longer return borrowed references (ex: PyDict_GetItem is part of
the stable ABI) and no longer steal references (ex: PyModule_AddObject)
- Disallow getting direct access into an object data without a
function to "release" the data. For example, PyBytes_AsString() gives a direct access into the string, but Python doesn't know when the C extension is done with it, and when it's safe to delete the object. Such API prevents to move Python objects in memory (implement a moving garbage collector in Python).
- Disallow dereferencing a PyObject* pointer: most structures must be
opaque. It indirectly means that accessing directly structure members must also be disallowed. PEP 670 and PEP 674 are partially fixing the issues.
All of these can be changed in the API. Not easily -- I mentioned the problem with testing the ABI, but there might be others -- but fixing these in the API first is probably the way to go.
The ABI can then be changed to align with the current API.