[IronPython] [python] Re: Announcement: Project to get someCPython C extensions running under IronPython

[Keith J. Farmer]

Forgive my non-C-ness (it's been a long time since I wrote a native
module for Python), but aren't you now buying into a major
re-implementation of all the native Python standard library into C#?  

 

Assuming for a moment that few sane people will want to re-compile them
from source, it seems much easier to just use the current C++/CLI
compiler from MS (not MC++), as recommended on the Mono site:
http://www.mono-project.com/CPlusPlus (#CodeGeneration)

 

Then conditionally switch out the CRT references with a CLR version:

 

#ifdef CLR

Tasty, non-CRT happy-happy

#else

Evil, CRT hurty-hurty

#endif

 

.. Then maybe re-submit back to CPython-land.

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt
Hagenlocher
Sent: Wednesday, October 17, 2007 2:31 PM
To: Discussion of IronPython
Subject: Re: [IronPython] [python] Re: Announcement: Project to get
someCPython C extensions running under IronPython

 

On 10/17/07, Michael Foord <fuzzyman at voidspace.org.uk > wrote: 

I would be sad if we chose any approach that couldn't work on Mono. :-(

 

I agree.  Assuming this rules out MC++, I think the next best approach
is (as Paolo suggests) to try to shift as much of the work to C# as
possible.

 

Here's an architecture to think about. Consider the following example
for PySequence_Length:

 

In C:

typedef int (__stdcall *PFN_iO)(PyObject *);

PFN_iO PFN_PySequence_Length;

void Set_PySequence_Length(PFN_iO callback)
{
    PFN_PySequence_Length = callback;
}
int PySequence_Length(PyObject * object)
{
    return PFN_PySequence_Length(object); 
}

In C#:

public delegate int PFN_iO(IntPtr object);

 

[DllImport("extension.DLL")]
public static extern void Set_PySequence_Length(PFN_iO callback);

public static int PySequence_Length(IntPtr obj_in)

{

    object o = ObjectConverter(obj_in);

    // Do something with o

    return result;

}

 

public static void SetApiFunctionsAtStartup()

{

    Set_PySequence_Length(PySequence_Length);

}

 

Ignoring exception-handling for now, the idea is to keep most of the
implementation in C# and to have the C# code register callback functions
as actual implementations for the parts of the Python API that we're
going to duplicate. 

 

This is idea is dependent on a kind of "global registry" of objects with
representations on both sides of the border.  Such a registry will
almost certainly be required in order to translate between the two -- if
for no other reason than to handle reference-counting and/or garbage
collection.  Any PyObject being passed across the boundary would then
actually be some kind of index into the registry. 

 

A "PyTuple_New" would call through the delegate into C# where (say) a
List<object> would be created and added to the registry, with its unique
identifer being passed back to the C caller as a "PyObject *". 

 

INCREF and DECREF on the C side would affect a reference count in the
registry. Once the DECREF takes the reference count down to zero, the
object is removed.  At that point, it may very well still be a valid CLR
object in use by other parts of the program -- just not by the C
extension. 

 

Objects actually defined in the C extension would be required to use
either PyObject_New or Py_NewReference as part of their initialization
in order for the proper fixups to happen.

 

 

What do you think?

 

--

Curt Hagenlocher

curt at hagenlocher.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ironpython.com/pipermail/users-ironpython.com/attachments/20071017/cb59e591/attachment.html