On 31 Jul 2018, at 13:25, Victor Stinner vstinner@redhat.com wrote:
Hi,
2018-07-31 13:01 GMT+02:00 Ronald Oussoren ronaldoussoren@mac.com:
With the regular API extension types are created by a (static) PyTypeObject structure, with the stable ABI you have to use a function based API to create and initialise the type. I expect that this is the major reason why there have been few attempts to migrate existing C extensions to the stable ABI.
Oh, I see. I recall issues with PyTypeObject. I added a page: https://pythoncapi.readthedocs.io/type_object.html
And I proposed:
- PyTypeObject structure should become opaquet
- PyType_Ready() should be removed
https://pythoncapi.readthedocs.io/bad_api.html#pytype-ready-and-setting-dire...
Can PyType_FromSpec() be used for all cases? It seems like at least some types cannot be defined with it, since there is an additional PyType_FromSpecWithBases() private function.
I have never seriously looked at this API, but I’m pretty sure that it was the intention this API could replace the existing API.
That said, I have a use case where this API isn’t sufficient, but that’s because I’m doing stuff I shouldn’t be doing. I’ve created PEP 447 <https://www.python.org/dev/peps/pep-0447/ https://www.python.org/dev/peps/pep-0447/> to do away with that need, but haven’t had the time yet to finish the PEP and update the implementation to the current master.
Another, unrelated, use-case I have involves subclassing PyUnicode_Type in C code, and add a new slot to store a native pointer. That requires access to the C structure for Unicode objects (and replicating the code to initialise those structures). The primary reason for doing this is that it is currently not possible to have types that behave like strings when passing values to C code (that is, values other than str that can be used with the “s” format specifier for PyArg_Parse). This could probably be solved by having yet another tp_as* slot in PyType_Object, but I haven’t spent time on thinking this through yet.
BTW. PyArg_Parse* is also an API that leaks implementation details: The “O” specifier results in a borrowed reference, and “s” returns a pointer to internal storage.
Ronald
P.S. Both use cases are in PyObjC