467,207 Members | 1,277 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,207 developers. It's quick & easy.

can't find win32api from embedded pyrun call

Jim
I am trying to figure out how to embed Python in a little C++ Windows
console app. Here's the code:

// Py_Initialize();
Py_InitializeEx(0);
PyRun_SimpleString("from win32com.client import *");

Here's what it does on the last line:

File "D:\Python\Lib\site-packages\win32com\__init__.py", line 5, in ?
import win32api, sys, ok
ImportError: No module named win32api

The same line runs fine in IDLE or at the command prompt. It also runs
without complaint if I run a release version of the app. To build the
debug version I had to build python42_d.lib/dll myself. The reason I
can't call PyInitialize is that it crashes with an "invalid signal"
error.

I don't think it's a path issue -- I've checked system path, sys.path,
pythonpath env var, and the pythonpath entry in the registry, all of
them loaded with directories including the one with win32api.pyd.
Besides, if it were an install or path problem, why would it work at
the command prompt?

Could it be a problem with the debug lib I built? Any suggestions are
welcome.

-- Jim

Jun 20 '06 #1
  • viewed: 2390
Share:
2 Replies
Hello Jim,
// Py_Initialize();
Py_InitializeEx(0);
PyRun_SimpleString("from win32com.client import *");

Here's what it does on the last line:

File "D:\Python\Lib\site-packages\win32com\__init__.py", line 5, in ?
import win32api, sys, ok
ImportError: No module named win32api

The same line runs fine in IDLE or at the command prompt. It also runs
without complaint if I run a release version of the app. To build the
debug version I had to build python42_d.lib/dll myself. The reason I
can't call PyInitialize is that it crashes with an "invalid signal"
error.

I don't think it's a path issue -- I've checked system path, sys.path,
pythonpath env var, and the pythonpath entry in the registry, all of
them loaded with directories including the one with win32api.pyd.
Besides, if it were an install or path problem, why would it work at
the command prompt?

IIRC you need to set the path explicitly in an embedded interpreter.
See the code in "site.py" (which again IMO is *not* imported when the
interpreter starts).

HTH,
Miki
http://pythonwise.blogspot.com/

Jun 20 '06 #2
Jim
Miki wrote:
IIRC you need to set the path explicitly in an embedded interpreter.
See the code in "site.py" (which again IMO is *not* imported when the
interpreter starts).


Thanks Miki. Actually that doesn't turn out to be the problem. If I
display sys.path within the embedded script, it shows the complete list
of paths, there is no need to pre-load.

The problem turned out to be a mismatch of parts. For one thing,
building the debug lib from Python sources using VS2005 leads to the
crash in PyInitialize (I don't know why others haven't run into this);
building with VS2003 did away with that. But that then led to the
well-known problem with a FILE* where the app is using one msvcrt and
the lib another. At some point in fixing these issues, the "cannot
find win32api" went away.

I now use this trick from a colleague which allows me to build a debug
version of my app but load the release version of the lib: bracket the
"#include python.h" statement with undef/redef of _DEBUG.

And this trick to get around the FILE* problem (since my app is VS2005
and the lib is 2003): instead of PyRun_SimpleFile, use
PyRun_SimpleString ("execfile(fname)"). I got this from the win32 FAQ.

I hope someone benefits from this, it cost me plenty to figure out.

-- Jim

Jun 20 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Matt Smith | last post: by
2 posts views Thread by Josh | last post: by
9 posts views Thread by Mayer | last post: by
5 posts views Thread by Frank Borell | last post: by
8 posts views Thread by Nikhil Patel | last post: by
3 posts views Thread by morris.slutsky@gmail.com | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.