[Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI (original) (raw)
Stephen J. Turnbull stephen at xemacs.org
Thu May 21 02:40:56 CEST 2009
- Previous message: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI
- Next message: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Benjamin Peterson writes:
2009/5/20 <skip at pobox.com>:
I suspect it's not really germane to this discussion but if the incref/decref functions were defined as inline would that effectively be like using the macro versions vis a vis ABI compatibility?
The code would be inlined into applications defeating the point of being able to change the implementation. :)
Hang on, are you sure Skip isn't on to something? If the APIs are defined in such way that by making them function calls they preserve ABI compatibility, while making them inline gives performance, then the user (in this case, I really mean the vendor of an application that contains C modules, I guess) can choose which route to go, right?
I suppose that Python itself could be built with inlined code internally, but also provide the ABI (at a cost in size, of course).
I don't know if this complexity is manageable or worth trying to manage, but isn't it conceivable that it could work?
I guess that's for the advocates of extending the promise of ABI compatibility to these APIs to show, though. I don't need it myself.
- Previous message: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI
- Next message: [Python-Dev] [unladen-swallow] PEP 384: Defining a Stable ABI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]