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

Jeffrey Yasskin jyasskin at gmail.com
Wed May 20 19:41:37 CEST 2009

On Wed, May 20, 2009 at 10:34 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

Jeffrey Yasskin <jyasskin gmail.com> writes:

Sorry, I didn't mean to get into a GIL debate. All I'm saying is that I don't think changing the definition of PyINCREF and PyDECREF justifies going to Python 4.0, so I don't think their definitions should be part of the ABI. If that's not what the ABI means, that's ok too. Consider, though, that if PyINCREF and PyDECREF are not part of the ABI, enabling the ABI-specific preprocessor symbol will hide them, which might (or might not!) annoy a lot of extension writers.

Yes, that's my intention. (Well, not the annoying part, but making them use Py_IncRef 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 Py_INCREF(x) expand to Py_IncRef(x) in ABI-compatibility mode.

More information about the Python-Dev mailing list