Embedding Python in Windows tutorial?
moof at boof.moof
Thu Oct 21 08:23:04 CEST 2004
Thanks a lot for the answers -- they were quite helpful. Anyone else have
I still haven't gotten around to doing this, I might put it off since it
seems like more work than I would think... as I said I thought this was the
"canonical" thing to do and it would be pretty much a cut and paste job from
Does anyone else work with Python and C/C++ regularly? I thought there
would be more experts here... or are people not using Windows?
Not to be rude, but it is a little disheartening that everyone jumps all
over that "warehouse" thread rather than something a little more mundane but
utilitarian... : )
"Daniel Dittmar" <daniel.dittmar at sap.corp> wrote in message
news:cl2n18$ltg$1 at news.sap-ag.de...
> Roose wrote:
> > 1. I heard Python23.dll is built with MS VC++ 6. I am using .NET 2003
> > 7.1). Is this a problem? I wouldn't think so since I am not statically
> > linking... but someone said the C runtime is different between the two?
> > When would that be a problem?
> - extensions compiled with .Net 2003 seem to run fine with Python 2.3
> - I've heard that Python 2.4 will use .Net 2003 anyway
> > 2. Any sample VS.NET projects / boilerplate DLL code that loads
> > Python23.dll into the? Sure this is probably pretty simple -- add an
> > include paths, add a DLL dependency... but I'm sure there is at least
> > gotcha and if I can avoid repeating other's mistakes, I'd prefer that.
> If you use the normal Python API, you link with the import lib
> python23.lib, which will load python23.dll. If you put python23.dll into
> the same directory as your application, everything should be fine.
> > 4. The program in question has no installer -- it is an internal tool,
> > people simply download the binaries .exe/.dll's/etc. from a source
> > system. Does that present any problems? Is all they need is
> > in their system dir, which is installed if you install Python? But I am
> I suggest that you distribute everything Python together with you
> application. I found that switching to a new Python version is a hassle
> when you have to tell everyone to do the upgrade.
> - distribute python23.dll in the same directory as your application
> - distribute the Python standard lib as a .zip archive
> -- use the script compileall.py to generate the .pyc files
> for the Python lib
> -- use the -d and -f options to set the source directory
> in the .pyc files. It is irritating if you get a Python traceback
> and the filenames look plausible, but don't exist. Something like
> "PYTHONROOT/os.py" makes it clear that the python files comes from
> the distribution.
> -- zip all the .pyc files into an archive (.py are optional)
> -- add that .zip file to your distribution
> -- add <python>/DLLs/zlib.pyd to your distribution (needed to import
> modules from .zip files)
> -- in your application: add that .zip file to the module search path,
> either by changing the environment variable PYTHONPATH or by
> manipulation sys.path through the Python API
> -- you can start simple by packing only the .py files. This will work,
> but it will be a bit slower as Python has to compile the files
> for every run of your application
> If you distribute Python together with your application, you should
> occasionally test that you have everything included:
> in the registry, rename
> HKEY_LOCAL_MACHINE/Software/Python/PythonCore/2.3. That way, your
> embedded Python won't be able to fall back on your installed Python.
> > going to need to write some Python wrappers for functions... does this
> > I need to use distutils and all that? One thing I didn't find clear is
> > distutils will "install" a module on your own machine -- but what do you
> > need to do to get it onto other's machines? (e.g. non-engineers who do
> > have compilers)
> Your wrapper functions are part of your application. You make them known
> to the Python runtime during your application, so there is no need to
> install them via distutils.
> > One of my concerns now is that it will decrease the
> > debuggability of the application. In a pure C/C++ app in VS.NET, it is
> > pretty simple to debug. But now I will have a layer of Python in
> > which could make it a big pain. In general this is kind of an "extra"
> You certainly shouldn't try to debug through the Python code. Set
> breakpoints on all your extension functions. Once you reached Python,
> use 'go' to go right through it.
> You should also have the ability to report all exceptions in scripts
> complete with backtraces. This will help you now with debugging and
> later your customers with their own scripts.
More information about the Python-list