[Python-Dev] PEP 384: Defining a Stable ABI (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Wed May 27 13:17:55 CEST 2009
- Previous message: [Python-Dev] PEP 384: Defining a Stable ABI
- Next message: [Python-Dev] PEP 384: Defining a Stable ABI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[PEP]
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) [MAL] Including PyINCREF()/PyDECREF() ? [Nick] I believe so - MvL deliberately left the fields that the ref counting relies on as part of the ABI. [MAL] Hmm, another slow-down. [MvL] ??? Why is "no change" a slow-down?
That was just a miscommunication - I misunderstood the sense in which MAL was using "Including". He was referring to the first part of the paragraph from the PEP (most macros become functions), but I answered assuming he was referring to the part in parentheses (some macros get to stay).
So to be perfectly clear: the Py_INCREF/Py_DECREF macros are available as part of the stable ABI because they qualify for the PEP's "definition only refers to features of the ABI" exception.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] PEP 384: Defining a Stable ABI
- Next message: [Python-Dev] PEP 384: Defining a Stable ABI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]