[Python.NET] problem with inheritance? ironpython ok, python.net - different

[Christian Heimes]

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