Re: Python loading library containing embedded python...
Martin v. Löwis [EMAIL PROTECTED] wrote: Brennus wrote: 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? Is this the debug build, by any chance? Microsoft broke support for ISO C in VS2005. The Python trunk has a work-around for that breakage. Good to hear, for my sanity at least. I was actually thinking Microsoft was losing or breaking C on purpose after using VS2005, and even VS2003 to some degree. I think it's some sort of tactic. That's another reason I don't want to continue using VS for Python. 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. More likely, you managed to mix msvcrt versions somehow. You need to inspect your resulting DLL in depends.exe; please report what it depends on. I can't manage to compile anything with VS when Code Generation is not set to the same type across projects. I guess I will try the VS 2005 route again with this and the VS2005 patches in mind. I am setting Code Generation the same across projects so I figured that meant I was using the same C runtimes. Also notice that you cannot use extension DLLs in your embedded Python: all extension DLLs depend on python2x.dll, so importing one of them leads to multiple copies of the Python code in your interpreter. Are there plans to move away from VS? Well, VS is the the platform compiler, so no. Of course, if you wanted that to happen, you could write a PEP, and explain what alternative compiler (plus alternative build procedure) should be used. I imagine MinGW's build process would be much easier. I *think* I have to keep two Python trees just to *easily* compile static and dynamic import lib files from Python VS. Otherwise, it is quite easy to overwrite a 3 meg static pythoncore.lib with the 200k dynamic/import version. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python loading library containing embedded python...
Martin v. Löwis wrote: Brennus wrote: I have a dll/so which embeds python. I can verify it works by compiling it as an executable and adding an appropriate main. Please explain in more detail how you did the embedding. Did you statically link the Python interpreter into your dll/so, or did you use a shared one? I compiled pythoncore.lib. I statically link this to my dll and define Py_BUILD_CORE before including Python.h. The only difference I can see with doing this vs linking the python dll dynamically is that Py_IsInitialized returns true when using the dll. This makes sense, but little else does. How can I make my dll/so with embedded python support use via ctypes? Whether you can do this at all depends on the fine details of embedding: e.g. what operating system, how precisely did you do the embedding, and so on. For example, on many Unix systems, you might end up with two definitions of all the Python symbols, at which point it depends on the precise linker command line options to determine what precisely happens (e.g. which of the definition of the symbol is used in what place). 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). Then your best bet is to *really* embed Python. I.e. link all symbols statically, preferably renaming them (if possible), and make sure that the resulting dll does neither reference nor expose any Python symbols. Given the different linkers on different systems, this is very tricky to implement. For now, I am testing this in Windows with Visual Studio. I will look into renaming the symbols, but I am not sure I understand why this is necessary. Surely two unrelated DLLs can exist in a process with the same function names? If not, I am surprised this problem hasn't been seen or even exploited by plugin competitors more often. Most of the time Py_Initialize and Py_IsInitialized works. High level tests with PyRun_SimpleString() crash in any DLL I use from ctypes, while working fine as an executable. -- http://mail.python.org/mailman/listinfo/python-list
Re: Language Semantics: @ symbol??
Enigma Curry [EMAIL PROTECTED] wrote: Sorry, for the noob question, but I haven't been able to find documentation on this matter. I've been looking for documentation that describes what the @function() syntax is all about. http://www.google.com/search?q=python+decorators -- http://mail.python.org/mailman/listinfo/python-list
Re: Python loading library containing embedded python...
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
Python loading library containing embedded python...
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). -- http://mail.python.org/mailman/listinfo/python-list
