Embedding Python in C++ and get rid of it again

[Manuel Klimek]

Hi folks,

I've got a problem:
I'm coding on xpermud, a scriptable mud client.
This one features multiple scripting languages
(perl and python at the very moment). The
big problem is, that we want the user to be
able to choose his scripting language at 
runtime (saved, for example, in a bookmark).
It was quite hard to get perl to do this part,
but unloading the library and reloading it
made this possible. At first this seamed to
work with python, too. In fact, it does, as
long as you don't start any modules that
depend on .so files. They just don't find
the symbols python exports. So I did lot's of
research and found out that setting the
LTDL_GLOBAL flag helps with this one. But then
the python .so has it's symbols globally and
can't be unloaded any more. Even worse, perl.so
can't be started afterwards (probably) because
of a symbol name clash. So why does python want
to have "hard"-exported symbols in .so libraries?
Only so that python module developers can
be more "dirty" in their programming ways? I
think from a software design point of view, that
this can't be a good solution (and this was
the _only_ thing where perl seemed to be designed
better, big compliment to the python developer
crew :-)
Now, our current solution is to disable loading
of other interpreters once python is loaded.
I'm not really glad with this one. Does
anybody know enough of python internals to
hint me some other solution? We tried so far:
- unloading the .so (doesn't work if there
  are global symbols)
- just letting the .so stay in (makes perl
  crash when called)
- forbidding the user to switch languages
  after going to python (which he probably'll
  do anyways ;-), but this is still annoying...)
- not using LTDL_GLOBAL, but this disables
  the use of .so modules (for example time)

Special question: Is there a different way to
get the python modules find the symbols they
need, some magic internal undocumented python
function we could call on the C++ side...?

thanks in advance for any hint,
  Manuel