Brian Lloyd wrote: > IP and python.net use pretty different models for this, since python.net > has to cooperate with the std python global interpreter lock (IronPython > does not replicate the GIL in its implementation). > > The GIL, in addition to the various restrictions .NET makes on interaction > with the GUI thread will probably make for some fun times and late nights > if you try to do anything too fancy ;)
It's no fun to debug a problem when .NET, the C python library and python code meet each other. It's a constant task switch between a C# debugger, gdb and Python. You don't want to debug it when threads join the battle. It may take hours before you even grasp which part of your code is causing trouble. I wish I could exercise more patience and spare more time on the debug support. Unfortunately Python's Py_DEBUG / Py_TRACE_REFS changes the memory layout and API calls a lot. It would be much easier to debug reference leaks and other problems with a debug build of Python. I think the use case of PythonDotNet is different from IronPython's use case. PythonDotNet doesn't aim to be another Python implementation or a replacement for IronPython. I usually explain it as a bridge between managed code/.NET/C# on the one side and CPython and C extensions on the other side. You should use IronPython if you want to do Python development under .NET. PythonDotNet is for people who need to embed Python C extensions in managed code or embed managed code in applications with a CPython interface. For example I'm experimenting with using and script a C# assembly with Python inside Blender. So far I haven't done much but the initial experiments are doing well. Christian _________________________________________________ Python.NET mailing list - [email protected] http://mail.python.org/mailman/listinfo/pythondotnet
