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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED] > 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 [EMAIL PROTECTED]
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
