[Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI

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 <at> 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 Py_INCREF and Py_DECREF
>> 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 Py_INCREF and Py_DECREF 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