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

[Michael Foord]

Martin v. Löwis wrote:
> Dino Viehland wrote:
>   
>> Dirkjan Ochtman wrote:
>>     
>>> It would seem to me that optimizations are likely to require data
>>> structure changes, for exactly the kind of core data structures that
>>> you're talking about locking down. But that's just a high-level view,
>>> I might be wrong.
>>>
>>>       
>> In particular I would guess that ref counting is the biggest issue here.
>> I would think not directly exposing the field and having inc/dec ref
>> Functions (real methods, not macros) for it would give a lot more
>> ability to change the API in the future.
>>     
>
> In the context of optimization, I'm skeptical that introducing functions
> for the reference counting would be useful. Making the INCREF/DECREF
> macros functions just in case the reference counting goes away is IMO
> an unacceptable performance cost.
>
> Instead, such a change should go through the regular deprecation
> procedure and/or cause the release of Python 4.0.
>
>   
>> It also might make it easier for alternate implementations to support
>> the same API so some modules could work cross implementation - but I
>> suspect that's a non-goal of this PEP :).
>>     
>
> Indeed :-) I'm also skeptical that this would actually allow
> cross-implementation modules to happen. The list of functions that
> an alternate implementation would have to provide is fairly long.
>
>   

Just in case you're unaware of it; the company I work for has an open 
source project called Ironclad. This *is* a reimplementation of the 
Python C API and gives us binary compatibility with [some subset of] 
Python C extensions for use from IronPython.

http://www.resolversystems.com/documentation/index.php/Ironclad.html

It's an ambitious project but it is now at the stage where 1000s of the 
Numpy and Scipy tests pass when run from IronPython. I don't think this 
PEP impacts the project, but it is not completely unfeasible for the 
alternative implementations to do this.

In particular we have had to address the issue of the GIL and extensions 
(IronPython has no GIL) and reference counting (which IronPython also 
doesn't) use.

Michael Foord



-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog