Victor Stinner schrieb am 05.09.2018 um 12:21:
I would like to use "PyObject*" as an opaque thing because I would like to be able to implement tagged pointer for example. If you store an integer inside a "PyObject*", there is no PyObject structure anywhere. There is no linked PyTypeObject anywhere.
But all existing C extensions really want a "PyObject*" which behaves as it's a real Python object with an associated PyObject structure linked to a concrete PyTypeObject. So in some places, we need to produce temporary PyLongObject which represent the integer stored in the tagged pointer.
Borrowed references are a blocker issue for that.
You keep saying that, but I'm yet to see any proof for this broad assumption. I can see why macros that reach directly into data structures are a problem, e.g. PyTuple_GET_ITEM(), or functions like PyDict_GetItem() that return a borrowed reference to something that the caller does not control directly.
But that's not a problem of borrowed references per se. It's a problem with borrowed references that refer to something that is difficult to control for the user.
Macros like Py_TYPE() and Py_SIZE() are a good thing, because they make it easy to migrate APIs, not difficult.
Stefan