RetroSearch Browse

Wed May 20 22:10:48 CEST 2009 · http://mail.python.org/pipermail/python-dev/2009-May/089714.html

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 PyAST_FromNode
> (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
---------------------------------------------------------------

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2009-May/089714.html below:

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