On Fri, Mar 1, 2019 at 10:11 AM Neil Schemenauer <nas-python@arctrix.com> wrote:
Is this an argument for not introducing a PyHandle data type? Do you think it is better just to make PyObject work as handles?
To answer your question somewhat obliquely, I believe that it is possible to make the C-API more amenable to alternative Python implementations with incremental changes to the C-API that could be absorbed by third-party code over a series of releases. I also believe that improving PyObject* does not preclude providing a better abstraction like a PyHandle. I suspect many of the API work needed to make PyObject* better would be required to make even PyHandle possible.
So, what's your opinion on that choice? Not requiring a one-to-one
mapping for the handles makes things easier for the runtime but the API is harder to use correctly. Should we follow the JNI model or should we pay the cost to get one-to-one mapping?
I think a lot of details would have to be considered to make the right decision. For example, instances of types created in the C-API can be allocated outside of the Python heap. Would that feature be preserved? You could keep it with PyObject* but it might be harder to do with PyHandle.
Possible other sources of ideas: Common Lisp, LuaJIT, Smalltalk implementations, Erlang, Haskel implementations. Compared to those, I would suspect JNI is much more heavily used in practice.
Those would be good starting places. I know that Common Lisp and Smalltalk systems typically provide an FFI which is more minimal compared to the C-API.