[capi-sig]Changing extension source code to use PyHandle
It seems to me that all the new proposals, whether just hiding existing implementation details or moving to some new object id or tagged pointer system, will require extension module writers to replace PyObject * with PyHandle
And extension writers should also not be accessing struct fields in objects or type records directly, so we also want to replace eg type->tp_str with some kind of macro or inline function.
So as a first step, we should add a typedef for PyHandle to Python.h (well, most likely within object.h) and macros defined for all or the most common object / type struct members.
We can do this now without breaking any existing code. (Uh, right?) Then interested people can experiment with new ideas and APIs and we all get some idea of how hard a final changeover would be.
My other suggestion is that once the new typedefs and macros are in Python.h, announce that Python 4.0 won't guarantee source code compatibility for existing extension code.
--
cheers,
Hugh Fisher
On 2019-03-06, Hugh Fisher wrote:
So as a first step, we should add a typedef for PyHandle to Python.h (well, most likely within object.h) and macros defined for all or the most common object / type struct members.
I would prefer to make a separate Python extension module interface project (aka a shim layer). So, instead of compiling your extension module against the CPython source and headers, you would compile using the shim. That way, we can experiment and more easily change our mind about the API. People will be annoyed if we do experiments inside Python.h.
If I had unlimited resources, I would try to convert a bunch of extension modules to use that shim layer. You would quickly find out how difficult it is to change the source code for the extensions (must be easy to do) and what breaks due to API behavior changes (e.g. if we decide not to give one-to-one handle/object correspondence).
Regards,
Neil
participants (2)
-
Hugh Fisher
-
Neil Schemenauer