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

[Michael Foord]

Martin v. Löwis wrote:
>>>> 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.
>>     
>
> I was unaware indeed; thanks for pointing this out.
>
> IIUC, it's not just an API emulation, but also an ABI emulation.
>
>   

Correct.

>> 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.
>>     
>
> I think this somewhat strengthens the point I was trying to make: An
> alternate implementation that tries to be API compatible has to consider
> so many things that it is questionable whether making Py_INCREF/DECREF
> functions would be any simplification.
>   

It would actually have been helpful for us, but I understand that it 
would be a big performance hit. The Ironclad garbage collection 
mechanism is described here:

http://www.voidspace.org.uk/python/weblog/arch_d7_2009_01_24.shtml#e1055

We artificially inflate the refcount of all objects that Ironclad 
creates to 2 and hold a reference to them on the .NET side to make them 
ineligible for garbage collection.

Because we can't always know when objects have been decreffed back down 
to 1, there are some circumstances when we have to scan all the objects 
we are holding onto. If their refcount is only 1 then we no longer need 
to hold a reference them. When nothing is using them on the IronPython 
side either normal .NET garbage collection kicks in and the IronPython 
proxy object has a destructor that calls back into Ironclad and uses the 
CPython dealloc method.

> So I just ask:
> a) Would it help IronClad if it could restrict itself to PEP 384
>    compatible modules?
> b) Would further restrictions in the PEP help that cause?
>   

I've forwarded these questions to the lead developer of Ironclad 
(William Reade) along with a link to the PEP. He isn't on Python-dev so 
I may have to be a proxy for him in discussion. His initial response was 
"looks pretty sweet".

Michael

> Regards,
> Martin
>   


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