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

Nick Coghlan ncoghlan at gmail.com
Wed May 20 22:10:48 CEST 2009

Martin v. Löwis wrote:

Functions and function-like Macros ----------------------------------

All functions starting with Py are not available to applications. Also, all functions that expect parameter types that are unavailable to applications are excluded from the ABI, such as PyASTFromNode (which expects a node*). All other functions are available, unless excluded below. Function-like macros (in particular, field access macros) remain available to applications, but get replaced by function calls (unless their definition only refers to features of the ABI, such as the various Check macros) ABI function declarations will not change their parameters or return types. If a change to the signature becomes necessary, a new function will be introduced. If the new function is source-compatible (e.g. if just the return type changes), an alias macro may get added to redirect calls to the new function when the applications is recompiled. If continued provision of the old function is not possible, it may get deprecated, then removed, in accordance with PEP 7, causing applications that use that function to break.

Something I haven't seen explicitly mentioned as yet (in the PEP or the python-dev list discussion) are the memory management APIs and the FILE* APIs which can cause the MSVCRT versioning issues on Windows.

Those would either need to be excluded from the stable ABI or else changed to use opaque pointers.

Cheers, Nick.

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

More information about the Python-Dev mailing list