Python DLL in Windows Folder

[Lie]

On Dec 27, 12:30 am, "Markus Gritsch" <m.grit... at gmail.com> wrote:
> On 26/12/2007, Lie Ryan <lie.1... at gmail.com> wrote:
> > > On Dec 25, 2007 4:43 PM, Markus Gritsch <m.grit... at gmail.com> wrote:
> > > On 24/12/2007, Lie <Lie.1... at gmail.com> 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.