Forced to Embed?

[Lloyd]

Hi

After researching on Extending and Embedding it appears Extending is
favoured greatly over Embedding. I've tested Boost::Python successfully
in a test project but have run into an issue.

I have about 10 shared libraries that up until now have only been
statically linked into an application and used from C++. I'd like to
expose a lot of this functionality as different Python modules ( core,
network, input, etc ), however the interdependency between the libraries
seem to prohibit this. The library dependencies are in a tree heirarchy
with the basic core library at the bottom.

As far as I can tell I have to export these all in one massive module as
there is no way for the different python modules to directly communicate
with each other?

Because of this I have to assume any application specific code would
have to be placed in this massive module aswell and thus the whole
module setup is moot and I might aswell embed python in the application
and import the different interfaces as modules into the python namespace
while still having them communicate directly because they're in the same
executable.

I'd prefer to extend while using the normal python interpreter but I see
no way around this without a large restructure?

Thanks for any suggestions...

[Miki Tebeka]

Hello Lloyd,

I have about 10 shared libraries that up until now have only been
statically linked into an application and used from C++. I'd like to
expose a lot of this functionality as different Python modules ( core,
network, input, etc ), however the interdependency between the libraries
seem to prohibit this. The library dependencies are in a tree heirarchy
with the basic core library at the bottom.

As far as I can tell I have to export these all in one massive module as
there is no way for the different python modules to directly communicate
with each other? What do you mean by "communicat e"? Whey isn't "import" good enough?

Because of this I have to assume any application specific code would
have to be placed in this massive module aswell and thus the whole
module setup is moot and I might aswell embed python in the application
and import the different interfaces as modules into the python namespace
while still having them communicate directly because they're in the same
executable.

I'd prefer to extend while using the normal python interpreter but I see
no way around this without a large restructure?

You can have one Python module that is the interface to the C++ module and
it will be structured the way you want (using classes, modules ...).

Bye.
--
------------------------------------------------------------------------
Miki Tebeka <mt*****@qualco mm.com>
http://tebeka.bizhat.com
The only difference between children and adults is the price of the toys

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: GnuPT 2.7.2

iD8DBQFDZxTW8jA dENsUuJsRAojWAK C8yh5IqyKWL7ekh IAHki9l3oM03wCe P2T9
bO8Zl5waTNLcOMI 7ooN9i5s=
=psvG
-----END PGP SIGNATURE-----

[Magnus Lycka]

Lloyd wrote:

As far as I can tell I have to export these all in one massive module as
there is no way for the different python modules to directly communicate
with each other?

I don't see how this is a Python issue. If you can make these modules
into shared objects / dynamically linked libraries, and make a C++
application use them as such, you should be able to get this to work
even if the main program is a Python program that imports them via
a wrapper, right? Or is there something I missed? (I'm no expert in
writing extensions.)

I know that it's possible to mess up C/C++ code in such a way that
dynamic linking requires a major rewrite, but I don't see that this
has anything to do with Python except that you got two bright ideas
at the same time: Use Python as main and modularize the code better.

I guess you *should* pull up your sleeves and clean up your code, but
it's not always that we get the time to do what we should...