Good to hear that it's moving in that direction.

I was hoping that swig would provide the embedding of the relevant interpreters automatically.  Something like this:

1) I swig a Perl module with Python as the target.
2) Python starts up the library including the Perl interpreter.
3) It just works.

However, one complicated issue is what happens if there are multiple Perl libraries or the Perl library wants to call out to a Python module that is visible in the originating Python process.  It seems as if it would be nice if there were a mostly automatic way to keep one copy of each interpreter and register modules into a global registry.  I haven't thought about it too much.


On Friday, January 24, 2014 3:39 PM, Robert Stone <> wrote:
On Tue, Jan 21, 2014 at 08:42:43PM -0500, Bob Algiers wrote:

> Swig is great.  I use it at work (nvidia) to speed up perl programs.
> Swig would be even more powerful if it could call the scripting languages from c/c++.  If you could normalize to c++, then you could call any of your scripting languages from any other.  I would use this to provide python bindings to perl modules.

        It should soon be possible to get method dispatch from C++ into
Perl implementations of C++ base classes using the "directors" feature.
I believe this is due to be included in the next major release.  However
to provide Python with a library that can invoke Perl code, the library
would need to create and maintain it's own embedded Perl interpreter.

        I have not yet had a chance to try this myself, but I believe it
should be possible.  Perl is not *that* difficult to embed in an
application, though embedding in a library can be tricky. has some details.