[Python-Dev] Using PEP384 Stable ABI for the lzma extension module (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Tue Oct 4 19:28:41 CEST 2011

Amaury: thanks for your experiment and your report.

- I replaced PyBytesGETSIZE() with PySIZE(), which is OK, and PyBytesASSTRING() with PyBytesAsString(), 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 PyTYPE(self)->tpfree((PyObject *)self); with PyObjectDel(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.

- PyBytesResize() is missing; I moved it under a PyLIMITEDAPI 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 Pybuffer structure is required (only for two fields: buf and len), as well as PyBufferRelease()

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.

- PyTypeFromSpec() does not call PyTypeReady(), which caused crashes in new.

Oops :-)

Regards, Martin

More information about the Python-Dev mailing list