Neil Schemenauer schrieb am 28.02.19 um 19:43:
On 2019-02-28, Stefan Behnel wrote:
I think the PyHandle idea has the best chance of producing a good end result. I suspect PEP C doesn't go far enough to solve the problems for alternative Python implementations. They really want PyObject to be an opaque handle-like object. Trying to make the existing C-API work like that seems like a nearly impossible task.
Why do you think so? It looks like a relatively simple change to me, mostly just replacing "Py_INCREF(obj)" with "obj = Py_INCREF(obj)" in user code, and then clean up a couple of corner cases here and there.
I don't understand why you think Py_INCREF() would have to return a new pointer. That doesn't seem necessary to me or too relevant to making PyObject and PyTypeObject opaque types.
Interesting. I actually don't understand what PyTypeObject has to do with this. :)
Py_INCREF() needs to return a new handle (whether that's a pointer or not is an unimportant detail for now).
I think the challenge is for all the extension module code that looks inside those structs, e.g.
ob->ob_typeor
Py_TYPE(ob)->tp_somethingYou have to provide APIs that replace all those struct member accesses.
I understand that "obj->ob_type" might be problematic (although that does not even seem sure yet), but what is the problem with "tp->tp_something"?
ob_type is accessed in a lot more but it is not too terrible to replace those references with Py_TP(ob) (version of Py_TYPE that casts the arg to PyObject *). I did that for my tagged pointer experiment and it wasn't too bad.
I think it would still be nice to allow at least fast type checks.
Stefan