Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nntp-feed.chiark.greenend.org.uk!ewrotcd!news.nosignal.org!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
From: "Leonard, Arah" <Arah.Leonard@bruker-axs.com>
To: "python-list@python.org" <python-list@python.org>
Subject: RE: Failed to import a "pyd: File When python intepreter embed in C++	project
Thread-Topic: Failed to import a "pyd: File When python intepreter embed in C++	project
Thread-Index: AQHN+RQVGX94ReWdqEuPVk5Wm3XuPZhXEuHA
Date: Wed, 23 Jan 2013 16:28:58 +0000
References: <552da0d2-e744-4ce2-8204-14a7274515de@googlegroups.com>
In-Reply-To: <552da0d2-e744-4ce2-8204-14a7274515de@googlegroups.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.908.1358958543.2939.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:37488

> I create a pyd File named "testPyd" with boostPython,and then I import th=
e testPyd module into "test.py", it works perfect!
> But when I embeded the python interpreter into my C++ project and run the=
 "test.py", it comes out a "ImportErr: no module named testPyd".
> It has confused me for two days and I googled for long time,but I can't f=
ind the answer!
> Anybody here can help me ?
> Thank you!
>=20

	Ah, that sounds familiar.  I have a small bit of experience with Boost.  I=
 could be wrong, because once you start mixing it up with Boost all sorts o=
f weird things can happen (especially on a MS compiler, because no one test=
s for Windows, let alone a pay-for compiler) but my experience has shown th=
at if you get that specific import error, what it actually means is just th=
at the PYD import failed for ANY reason.  It has nothing to do with the nam=
e or that the PYD couldn't be found.  Just that somewhere, at some time dur=
ing import, it failed to fully load.

	In my use a lot of times it was either that a DLL that module depended on =
wasn't in the path, or my favorite kicker, that some compile/link flags bet=
ween the PYD and the Python interpreter don't match well enough.  (Usually =
from mixing debug and release builds together.)

	From what I've seen anyway, the Python interpreter really doesn't like bei=
ng built in a traditional debug mode, so I always do a release build of it.=
  It's a little inconvenient, but in the linker flags you can still set you=
r PYDs to generate debug information even in release builds, so you can sti=
ll run the debugger on them when you attach to the process of the python in=
terpreter EXE.  And especially be sure to use the RELEASE runtime library f=
lag (such as /MD) instead of the debug flag (such as /MDd).

	That's as much as I know anyway.  Though depending, if you add any new tem=
plates/libraries into Boost (such as for NumPy ndarray), you also may need =
to use the /DBOOST_ALL_NO_LIB compiler macro on an MS compiler because MS d=
oesn't adhere to template standards correctly and you often end up with mul=
tiply-defined functions if you don't use that macro.  If I remember correct=
ly.  (It's been a while.)

	That and you may be picking up variable length arrays out of your teeth, r=
eplacing chunks of code with the use of new and delete operators.  No one t=
ests for Microsoft and the MS compiler is way behind in adhering to C/C++ s=
tandards, and VLAs pop up a lot.

	Hopefully something in all of this helped.  Boost can be ... daunting.  I =
get it, in theory.  But in practice it often hurts my head.  ;)

Sincerely,
Arah Leonard