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

["Martin v. Löwis"]

>>>> The structure of type objects is not available to applications;
>>>> declaration of "static" type objects is not possible anymore
>>>> (for applications using this ABI).
>>> Hmm, that's going to create big problems for extensions that
>>> want to expose a C-API for their types: Type checks are normally
>>> done by pointer comparison using those static type objects.
>> They would just have to expose "MyExtensionPrefix_MyType_Check" and
>> "MyExtensionPrefix_MyType_CheckExact" functions the same way that types
>> in the C API do.
> 
> Hmm, that's a function call per type check and will slow things
> down a lot, esp. when working with APIs that deal a lot with
> these objects.

See my other response. You can continue to provide _Check
macros; knowledge of the structure of types is not necessary to
perform such checks.

> The typical way to implement these type checks is via a simple
> pointer comparison (falling back to a function for sub-types).
> That's cheap and fast.

And will continue to be available to ABI-compliant extensions.

>>> Including Py_INCREF()/Py_DECREF() ?
>> I believe so - MvL deliberately left the fields that the ref counting
>> relies on as part of the ABI.
> 
> Hmm, another slow-down.

??? Why is "no change" a slow-down?

> This is not much of an issue if the C runtime DLL doesn't change
> between releases, but it becomes a problem when they do e.g.
> due to an upgrade to a new MSVC++ compiler version or in case
> the extension was downloaded pre-compiled from pypi or some
> other site.

What problem specifically may occur?

Regards,
Martin