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 A*P*Is are defined in such way that by making them *function calls* they preserve A*B*I 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4