Using python23 to develop an extension for an application that has python22 embedded

[John Underwood]

Can I use python23_d and python23 to develop an extension for a
commercial application uses python22.dll? (Providing that I do not use
any new features found only in 2.3.)

I would bulld version 2.2 but I am having trouble doing this with
Visual Studio .NET Standard. (There is a well documented problem with
version 2.2 (involving largeint.h) and VS.NET but none of the
solutions that I found have worked.)

On the other hand, I have successfully built release and debug
versions of pythoncore with VS.NET.

Thanks

 

[Michael Geary]

Can I use python23_d and python23 to develop an extension for a
commercial application uses python22.dll? (Providing that I do not use
any new features found only in 2.3.)

I would bulld version 2.2 but I am having trouble doing this with
Visual Studio .NET Standard. (There is a well documented problem with
version 2.2 (involving largeint.h) and VS.NET but none of the
solutions that I found have worked.)

On the other hand, I have successfully built release and debug
versions of pythoncore with VS.NET.

Why don't you just install the binary version of 2.2? That would be easier.
You can have 2.2 and 2.3 installed on the same machine with no problem.

http://www.python.org/2.2.3/

If 2.3 is the version you use most often, you may want to reinstall it after
installing 2.2, so that your Windows file associations point to it. You can
just reinstall 2.3 on top of your previous 2.3 installation. (Or maybe
there's an easier way to do this.)

-Mike

 

[John Underwood]

Why don't you just install the binary version of 2.2? That would be easier.
You can have 2.2 and 2.3 installed on the same machine with no problem.

http://www.python.org/2.2.3/

If 2.3 is the version you use most often, you may want to reinstall it after
installing 2.2, so that your Windows file associations point to it. You can
just reinstall 2.3 on top of your previous 2.3 installation. (Or maybe
there's an easier way to do this.)

-Mike

I have both 2.2 and 2.3 installed on my computer. My problem has to do
with Visual Studio .NET which will build 2.3 but will not build 2.2.
(MS removed largeint.h which is required by pythoncore in 2.2 when
they went from Visual C++ 6 to VS.NET. I tried supplying largeint.h to
VS.NET but that did not work.)

Since I cannot build 2.2, I do not have python22.dll or python22_d.dll
(the debug version). (They are not shipped with python you have to
produce them yourself.)

The commercial application to which I need to add an extension has
python22.dll in its runtime folder. I have no control over this
application and have to use whichever version they have chosen.

Since I do have python23.dll and python23_d.dll (from a successful
build of 2.3), can I use these to develop an extension for the
aforementioned commercial application if I stay away from any new
features in 2.3 (but not in 2.2)?

-John

 

[Michael Geary]

I have both 2.2 and 2.3 installed on my computer. My problem has to do
with Visual Studio .NET which will build 2.3 but will not build 2.2.
(MS removed largeint.h which is required by pythoncore in 2.2 when
they went from Visual C++ 6 to VS.NET. I tried supplying largeint.h to
VS.NET but that did not work.)

Since I cannot build 2.2, I do not have python22.dll or python22_d.dll
(the debug version). (They are not shipped with python you have to
produce them yourself.)

The executable Python installer for Windows does install pythonXX.dll. You
should find python22.dll and python23.dll in your Windows system32
directory.

Do you need python22_d.dll at all? I would think you'd need it only if you
were actually debugging the Python interpreter itself. I've never needed a
debug version of the Python DLL to debug ordinary Python code.

The commercial application to which I need to add an extension has
python22.dll in its runtime folder. I have no control over this
application and have to use whichever version they have chosen.

Paint Shop Pro?

Since I do have python23.dll and python23_d.dll (from a successful
build of 2.3), can I use these to develop an extension for the
aforementioned commercial application if I stay away from any new
features in 2.3 (but not in 2.2)?

Are you talking about source code compatibility only? Sure, as long as you
use only language features available in both the old and new versions. You
can't use .pyc bytecode files from one version with a different version.

Anyway, I must be missing something here, because I would think you could
simply develop with your installed Python 2.2 and run the code under your
target application. You shouldn't have to be worrying about any of the stuff
you're dealing with.

-Mike

 

[Andrew MacIntyre]

Since I do have python23.dll and python23_d.dll (from a successful
build of 2.3), can I use these to develop an extension for the
aforementioned commercial application if I stay away from any new
features in 2.3 (but not in 2.2)?

You can do the development, but you won't be able to directly distribute
the resulting extension because it will have been linked with python23.dll
when it needs to be linked with python22.dll.

To make things easier to fudge later, you make sure that your extension is
Distutils'ified from the beginning.

You can then use another compiler supported by the Distutils (MS CL
non-optimising compiler, MinGW, Borland etc) to build the distributable
extension in either a Python 2.2 or 2.3 installation, without risking
mixing C runtime library mismatches (VS.NET uses a different CRT than
VS6 I understand). If using a 2.3 installation, you'll need to substitute
a 2.2 import library when building the final distributable version.

The Distutils setup.py script can then provide the installation harness.

 

[John Underwood]

The executable Python installer for Windows does install pythonXX.dll. You
should find python22.dll and python23.dll in your Windows system32
directory.

Do you need python22_d.dll at all? I would think you'd need it only if you
were actually debugging the Python interpreter itself. I've never needed a
debug version of the Python DLL to debug ordinary Python code.


Paint Shop Pro?

Curious Labs - Poser 5

Are you talking about source code compatibility only? Sure, as long as you
use only language features available in both the old and new versions. You
can't use .pyc bytecode files from one version with a different version.

Yes, although I'll have to check into the .pyc bytecode issue - which
I don't think is a problem.

Anyway, I must be missing something here, because I would think you could
simply develop with your installed Python 2.2 and run the code under your
target application. You shouldn't have to be worrying about any of the stuff
you're dealing with.

May be it comes down to the approach taken to debug an extension. (I'm
new to Python - as you've probably guessed - and debugging mixed
language situations.)

To use the dubugging features of Visual Studio to debug my extension
code, I thought I needed to use python22_d.dll (the debug version fo
python22.dll). Is this correct? If so, I have not been able to produce
it with Visual Studio .NET because of the problems VS has with 2.2.

On the other hand, would it be better to debug the extension without
the Python interface (in other words, debug the internals of the
extension that are not dependent on Python) before attempting to test
the Python interface (which could be performed with python22.dll)?

-John

 

[Michael Geary]

May be it comes down to the approach taken to debug an extension.
(I'm new to Python - as you've probably guessed - and debugging
mixed language situations.)

To use the dubugging features of Visual Studio to debug my extension
code, I thought I needed to use python22_d.dll (the debug version fo
python22.dll). Is this correct? If so, I have not been able to produce
it with Visual Studio .NET because of the problems VS has with 2.2.

On the other hand, would it be better to debug the extension without
the Python interface (in other words, debug the internals of the
extension that are not dependent on Python) before attempting to test
the Python interface (which could be performed with python22.dll)?

Oh! I think I just realized what I was missing. Is your Poser extension part
Python and part C/C++? I was assuming it was pure Python.

If it was pure Python, then of course it wouldn't matter if you had the
debug version of python22.dll. You'd use the debugging facilities that the
Python interpreter provides for Python code, which don't depend on having
the debug version of the interpreter.

If you were debugging code in the Python interpreter itself, then you would
certainly need the debug version of python22.dll.

But are you are developing both some Python code and an extension DLL
written in C/C++? In that case, it still wouldn't be necessary to have the
debug version of python22.dll, any more than you need a debug version of the
Windows DLLs such as kernel32.dll and user32.dll. You would just build a
debug version of *your* DLL. Set the Debugging options in your VS.NET
project properties to run Poser, and you'll be good to go. You can set
breakpoints in your DLL, trace through the code, etc. The only limitation
will be that you can't trace through the code inside python22.dll. Only if
you need to do that would you need a debug version of that DLL.

-Mike

 

[John Underwood]

Oh! I think I just realized what I was missing. Is your Poser extension part
Python and part C/C++? I was assuming it was pure Python.

There is a Python front-end (using tkinter). This is not implemented
as an extension but is simply a script that runs in Poser. It imports
the extension part (which is coded in C/C++).

If it was pure Python, then of course it wouldn't matter if you had the
debug version of python22.dll. You'd use the debugging facilities that the
Python interpreter provides for Python code, which don't depend on having
the debug version of the interpreter.

If you were debugging code in the Python interpreter itself, then you would
certainly need the debug version of python22.dll.

But are you are developing both some Python code and an extension DLL
written in C/C++? In that case, it still wouldn't be necessary to have the
debug version of python22.dll, any more than you need a debug version of the
Windows DLLs such as kernel32.dll and user32.dll. You would just build a
debug version of *your* DLL. Set the Debugging options in your VS.NET
project properties to run Poser, and you'll be good to go. You can set
breakpoints in your DLL, trace through the code, etc. The only limitation
will be that you can't trace through the code inside python22.dll. Only if
you need to do that would you need a debug version of that DLL.

I tried a small extension DLL as a test using your suggestion. I could
debug in VS.NET without the need of python22_d.dll which is all I
need.

Many thanks for the help.

Regards,
-John

 

[Michael Geary]

I tried a small extension DLL as a test using your suggestion.
I could debug in VS.NET without the need of python22_d.dll
which is all I need.

Many thanks for the help.

Great! Glad it worked out.

Talk with you later,

Mike

 

[John Underwood]

You can do the development, but you won't be able to directly distribute
the resulting extension because it will have been linked with python23.dll
when it needs to be linked with python22.dll.

To make things easier to fudge later, you make sure that your extension is
Distutils'ified from the beginning.

You can then use another compiler supported by the Distutils (MS CL
non-optimising compiler, MinGW, Borland etc) to build the distributable
extension in either a Python 2.2 or 2.3 installation, without risking
mixing C runtime library mismatches (VS.NET uses a different CRT than
VS6 I understand). If using a 2.3 installation, you'll need to substitute
a 2.2 import library when building the final distributable version.

The Distutils setup.py script can then provide the installation harness.

Thanks for the advice. I have a Borland compiler that I'll try with
Disutils.

 

[Michael Geary]

You can then use another compiler supported by the
Distutils (MS CL non-optimising compiler, MinGW,
Borland etc) to build the distributable extension in
either a Python 2.2 or 2.3 installation, without risking
mixing C runtime library mismatches (VS.NET uses a
different CRT than VS6 I understand). If using a 2.3
installation, you'll need to substitute a 2.2 import
library when building the final distributable version.

Do I understand you correctly? It sounds like you are saying there is a
problem using a DLL built with VC6 and another DLL built with VS.NET in the
same application, but if you were to use a Borland or other compiler, then
you would avoid this problem.

That's not right at all. It's commonplace to have multiple DLLs loaded into
a Windows application, all built with different compilers and all using
different C runtimes. You can have one built with VC6, another with VS.NET,
and another with Borland or any other compiler. You certainly don't need to
build a DLL with Borland instead of VS.NET to avoid conflicts with another
DLL that was built with VC6.

If python22.dll has some incompatibility with other DLLs that are built with
VS.NET, then there is something seriously wrong with python22.dll.

If I misunderstood you, let me know what it was that you were getting at
here.

BTW, if you're distributing a DLL or application built with VS.NET, you do
need to make sure that the appropriate C runtime is available on the target
system. In many cases, the best way to do this is to compile and link with
the static C runtime instead of the DLL C runtime. If you use the DLL
version of the C runtime, you need to distribute it with your app or DLL.

To be sure of what other DLLs (C runtimes or whatever) your DLL or app
depends on, the best tool is Dependency Walker:

www.dependencywalker.com

-Mike