[Python-Dev] Using PEP384 Stable ABI for the lzma extension module

["Martin v. Löwis"]

Amaury: thanks for your experiment and your report.

> - I replaced PyBytes_GET_SIZE() with Py_SIZE(), which is OK,
> and PyBytes_AS_STRING() with PyBytes_AsString(), which may
> have a slight performance impact.

That's the whole point of the stable ABI: AS_STRING assumes that
there is an ob_sval field at a certain offset of the bytes object,
which may not be there in a future release. PyBytes_AsString
is indeed slower, but also more future-proof.

> - I replaced
>        Py_TYPE(self)->tp_free((PyObject *)self);
>    with PyObject_Del(self), I hope this is the same thing
>    (for a non-GC object)

If a subtype of self.__class__ would override tp_free, it
wouldn't be the same anymore.

I guess the API needs a way to read a slot from a type object.

> - _PyBytes_Resize() is missing; I moved it under a Py_LIMITED_API
>    section.

??? Are you proposing to add _PyBytes_Resize to the Py_LIMITED_API
set of functions? It's not even an API function in the first place
(it starts with an underscore), so how can it be a limited API function?

I think this whole notion of resizing immutable objects in the Python
C API is flawed. If you can't know how large a buffer is in advance,
first allocate a regular memory block, and then copy it into an object
when done.

> - For the "y*" argument spec, the Py_buffer structure is required
>    (only for two fields: buf and len), as well as PyBuffer_Release()

Yes, this was a debate in the API PEP. I originally had the buffer
API in the stable ABI, but was then advised to remove it, as it
may not be that stable at all.

I'll start a thread about extending the stable ABI soon; if people
now want to reconsider, it would be possible. However, taking something 
out of the stable ABI is not possible, so if we decide the buffer
API is stable, the structure is locked until Python 4.

> - PyType_FromSpec() does not call PyType_Ready(), which caused
>    crashes in __new__.

Oops :-)

Regards,
Martin