On Dec 27, 12:30 am, "Markus Gritsch" <[EMAIL PROTECTED]> wrote: > On 26/12/2007, Lie Ryan <[EMAIL PROTECTED]> wrote: > > > On Dec 25, 2007 4:43 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote: > > > On 24/12/2007, Lie <[EMAIL PROTECTED]> wrote: > > > > > (good programs are not DLL implementation specific > > > > Assume an application embedding Python being compiled with MSVC 8.0. > > > It uses the runtime msvcr80.dll. If you now pass objects created in > > > your application to the Python interpreter which is compiled with MSVC > > > 7.1 which uses msvcr71.dll, you are asking for serious trouble. It is > > > not a matter of being a "good program". > > > don't cut my word, good programs aren't DLL implementation specific and good > > DLL have consistent interface (consistent interface implies consistent > > behavior). Of course this is a bit "utopia", as most DLL would sadly have to > > change its interfaces once or twice and it is sometimes impossible for > > programs to be completely free from its DLLs implementation > > Instead of being upset about cutting your word (which was not my > intention, sorry about that), it would be nice if you could make a > statement concerning the problem I mentioned: Having an object being > created by one MSVC runtime, msvcr80.dll and passing it to another > one, msvcr71.dll.
I'm not upset, but if my wording seems to be like an upset person I'm sorry, English is not my first language, and I'm very bad at choosing words. A simple solution (but possibly inefficient, if the object is complex and need to be exchanged thousands of times) for the problem mentioned is to convert the object to a common agreed format that both sides can understand when transferring the data such as a simple string (not a string object, just simple string with no strings attached: pun (not) intended). In your case, which is: > Assume an application embedding Python being compiled with MSVC 8.0. > It uses the runtime msvcr80.dll. If you now pass objects created in > your application to the Python interpreter which is compiled with MSVC > 7.1 which uses msvcr71.dll, you are asking for serious trouble. It is > not a matter of being a "good program". No, you're not asking for trouble, you're passing the object to the Python DLL, not to the msvcr71 behind the Python so it shouldn't be a problem in a good designed program and DLL. This isn't a case about msvcr71 talking with msvcr8, nor it is msvcr71 with your program, nor it is msvcr8 with Python DLL, this is a case of Your Program talking to Python DLL. One way to solve this is: Assuming you don't have access to Python internals (although since Python is open source, you do have access) you could build a wrapper around Python Interpreter. The wrapper has two functions. One: accepts a string input (string as simple string, not string object) that describes the original object and returns a file that Python can pick with pickle. Two: accepts a pickled object and returns a string that describes the pickled object that Your Application could understand. This functions could be built in into Your Application, but the easiest way is to build the wrapper with Python, as you won't need to know how to read and write pickled file. For a simple case, where the object that needs to be passed is predetermined your function could just pass any data that is required to reconstruct the original object to the wrapper (for example, in a vector class, just the values of x, y, z), a versatile way to pass them is by command-line arguments, like "wrapper 1 2 3 > output". The wrapper would add any other required infos (methods, operator overloads, etc) before pickling the object and call the Python DLL to unpickle the object. For the vice versa case, the wrapper unpickle the file returned from Python DLL, and convert it to a format Your Program could understand, then notifying your program. Of course there may be other easier, more efficient ways to solve this problem, but this is a proof-of-concept that it is possible to compile your application in VS8 while still using the official VS<unknown> Python. But I can't think of a need why Python DLL needs to be used like this though > > > > If that's the case, just use the MSVC 7.1's compiled code, there won't > > > > be much difference. > > > > See above. > > > I think you don't get my point... if you don't modify the python interpreter > > (from what I understand, you just recompile your Python DLL without > > modification), there is no need to compile your own interpreter, it just > > makes problem and the performance benefits is outweighed by the problems of > > having to use 3rd party Python DLL (even if you don't modify the code and > > just recompile it, it is not the official release, thus 3rd party). > > I do get your point, but your point is maintaining compatibility > between two different *versions* of a DLL/Program. I am talking about > having a DLL/Program combination which uses different MSVC runtimes. It doesn't matter, your program is talking to the Python DLL not to the MSVC Runtimes behind it. If you pass an object to the DLL, a good program would use an intermediary format that is understood by both sides (Python DLL and Application), and not rely on the implementation behind the Pythond DLL to understand the object being traded. -- http://mail.python.org/mailman/listinfo/python-list
