Python 2.5 compatibility and interop.cs

Hello! I want to the pythonnet with Python 2.5 and .NET 2.0. So far I was able to fix the svn trunk revision 42 for .NET 2.0 using the tutorial from http://thread.gmane.org/gmane.comp.python.dotnet/576. I had to change clrModule to ModuleObject but it works under Python 2.4. Python 2.5 however doesn't work. I changed the dll in runtime.cs to internal static string dll = "python25"; in the hope that pythonnet doesn't need more changes. At first it looked promising. I was able to import clr and some other .NET assemblies. However using them is a different story. Python crashes everytime I try to use an object from an assembly. I compiled my own Python version in order to debug the error. It fails in typeobject.c:387 name = type_name(type, NULL); with an access violation. Something is trying to write to 0x00000000. I studied the pythonnet code a bit and I guess I have to alter interop.cs in order to make pythonnet compatible with Python 2.5. I don't know how it has to be changed and what it causing the error. Maybe ssize_t -> Py_ssize_t transition (I'm using a 32 bit Windows XP SP2)? Christian

I'm pretty sure there were some changes to type structures in 2.5, so probably the only sane thing to do would be to do a 2.5-specific branch :( The interop stuff is some fairly deep voodoo - it essentially generates a bunch of thunks and wrappers matching the in-memory layouts of various python type objects and things. What would need to be done is an assessment of what changed in 2.5, then go into interop and change / add offsets etc. accordingly. I can say with some experience that it won't be fun ;) My available time (and the fact that IronPython gets 99% of the oxygen these days) means that I probably won't be able to get to this any time soon, but I'd be more than happy to help anyone who wants to take this on in any way I can. -Brian On 7/1/07 5:33 PM, "Christian Heimes" <lists@cheimes.de> wrote:
Hello!
I want to the pythonnet with Python 2.5 and .NET 2.0. So far I was able to fix the svn trunk revision 42 for .NET 2.0 using the tutorial from http://thread.gmane.org/gmane.comp.python.dotnet/576. I had to change clrModule to ModuleObject but it works under Python 2.4.
Python 2.5 however doesn't work. I changed the dll in runtime.cs to
internal static string dll = "python25";
in the hope that pythonnet doesn't need more changes. At first it looked promising. I was able to import clr and some other .NET assemblies. However using them is a different story. Python crashes everytime I try to use an object from an assembly.
I compiled my own Python version in order to debug the error. It fails in typeobject.c:387
name = type_name(type, NULL);
with an access violation. Something is trying to write to 0x00000000.
I studied the pythonnet code a bit and I guess I have to alter interop.cs in order to make pythonnet compatible with Python 2.5. I don't know how it has to be changed and what it causing the error. Maybe ssize_t -> Py_ssize_t transition (I'm using a 32 bit Windows XP SP2)?
Christian

Brian Lloyd wrote:
I'm pretty sure there were some changes to type structures in 2.5, so probably the only sane thing to do would be to do a 2.5-specific branch :(
The interop stuff is some fairly deep voodoo - it essentially generates a bunch of thunks and wrappers matching the in-memory layouts of various python type objects and things. What would need to be done is an assessment of what changed in 2.5, then go into interop and change / add offsets etc. accordingly. I can say with some experience that it won't be fun ;)
My available time (and the fact that IronPython gets 99% of the oxygen these days) means that I probably won't be able to get to this any time soon, but I'd be more than happy to help anyone who wants to take this on in any way I can.
The docs don't mention a change to the type structure between 2.4 and 2.5. So far I found just two changes to the C api which may effect pythonnet: * C API: Many functions now use Py_ssize_t instead of int to allow processing more data on 64-bit machines. Extension code may need to make the same change to avoid warnings and to support 64-bit machines. See the earlier section 10 for a discussion of this change. * C API: The obmalloc changes mean that you must be careful to not mix usage of the PyMem_*() and PyObject_*() families of functions. Memory allocated with one family's *_Malloc() must be freed with the corresponding family's *_Free() function. But I suspect that internal changes to Include/object.h and children aren't mentioned in the migration docs. Dealing with memory addresses and offsets brings back memory from a time before I started to use Python ... I'll discuss it with my buddies. We may take the challenge. We don't have another choice since pythonnet looks like the easiest way to integrate our C# / .NET 2.0 library in Blender. Can you give me some tips how you debugged and created interops.cs when you developed the project? What tools were/are you using? Since pythonnet doesn't compile under Linux and Mono I suspect that I'm restricted to MS VS 2005. I can offer you a more direct communication channel (IRC freenode.net, ICQ, Jabber, MSN and Skype if you can stand my German accent ;) ). Christian

For your information: I've created an EXPERIMENTAL branch: https://pythonnet.svn.sourceforge.net/svnroot/pythonnet/branches/clr-2.0-pyt... It is NOT ready for production! Overloading and exception are currently broken but I'm working on it. I've also added project files and a solution file for MS VC#. The files are also working with the free Express Edition. Christian

I've fixed another bug related to the clr.preload flag and build a snapshot of revision 53. It's available under http://downloads.sourceforge.net/pythonnet/PythonNet-snapshot-r53.zip Christian
participants (2)
-
Brian Lloyd
-
Christian Heimes