>I have a dll/so which embeds python. I can verify it works by >compiling it as an executable and adding an appropriate main. > >I tried to write unit tests for this library with ctypes and a simple >python script. Access violations and other strange things result. I >suspect this is because I am basically embedding python in python at >this point. > >How can I make my dll/so with embedded python support use via ctypes? > >If Py_NewInterpreter is the answer, why does it hang indefinitely? > >The dll/so must support use in processes which might contain other >instances of Python. I can not change that requirement. Running via >ctypes is an easy test of this capability (or much of it I suspect).
I have solved my problem, or at least part of it by downgrading to Visual Studio 2003. For whatever reason, the same steps applied to Visual Studio 2005 result in massive problems. Even the python.exe compiled by VS 2005 throws A/Vs on startup. Does Python have to use Visual Studio? I have, of course, seen the MinGW Python patches and tutorials, but I am told I should not use anything but what Python was compiled with. Additionally, since a Python compiled with even VS 2005 is majorly broken, I am wary of using MinGW unless it is officially supported. Are there plans to move away from VS? It's horrible imho. I only upgraded from VS 6 at the recommendation I should use the same compiler used to compile the latest Python. I asked why, citing my own knowledge of struct alignment concerns between compilers, but was vaguely told it was very bad, and that FILE structs can differ. -- http://mail.python.org/mailman/listinfo/python-list
