[IronPython] Announcement: Project to get some CPython C extensions running under IronPython

[Paolo Molaro]

On 10/15/07 Giles Thomas wrote:
> Curt Hagenlocher wrote:
>  > My two cents would be this: using Managed C++, try for source 
> compatibility first. 

As python extensions use a C API, I don't see how Managed C++
would provide source compatibility. Managed C++ would be an ill-advided
method, IMHO.

> Binary compatibility would be a great thing in the long term - after 
> all, we don't want to run the risk of branching the target library's 
> codebase! - but my gut feeling is that you're right, Curt: it would be 
> much easier, at least as an exploratory first stage, to target source 
> compatibility only.  So perhaps we should start off in that direction.

I agree you should aim for source compatibility first, it's not like
people commonly use binary proprietary python modules (and if they do
it's the same people that wrote them and so can recompile).
Binary compatibility is harder to prove correct, anyway and you'll have
already your share of issues to overcome:)

> Does anyone know how this would impact the potential for Mono compatibility?

A Managed C++ implementation would be pretty useless for a mono port,
but I think it would be pretty useless for the .net runtime, as you need
to expose a C API anyway.
You'd have two components: the C API headers and some C code (this is
required in any case) is the first. Then you need an assembly that
translates from the C API to the IronPython model. You can write this
in nice C# + a few dllimports or with the ugly managed C++ (assuming
managed C++ can actually consume the python headers).

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better