[Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed May 20 22:07:08 CEST 2009

Jeffrey Yasskin wrote:

Yes, that's my intention. (Well, not the annoying part, but making them use PyIncRef instead for ABI compatibility is, I think, a good thing.) If they don't want ABI compatibility, they shouldn't ask for it. Giving them something else useful to ask for is why I mentioned an API compatibility mode.

To decrease the annoyance of having to change source code, we could have PyINCREF(x) expand to PyIncRef(x) in ABI-compatibility mode.

Forcing developers to choose between the speed of the INCREF/DECREF macros and the proposed ABI compatibility mode for the benefit of an as yet hypothetical GIL-less CPython API implementation seems more like a way to kill adoption of the ABI compatibility mode rather than a way to encourage the use of the IncRef/Decref functions.

The idea of allow an extension to explicitly version the stable ABI they're using with a macro like Py_ABI_VERSION is a good one though. I'd suggest using the Python version in hex (e.g. 0x020700 and 0x030200) rather than an ISO date though. That way an extension developer that wanted to ensure there code worked with a particular Python version and later could just define the right Py_ABI_VERSION rather than have to specifically compile against that earliest version.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list