embedding python

[Alex K. Angelopoulos]

Robin,

This may be utterly useless, but I'm tossing it out as an idea since some of the
details seem to fit... Have you considered indirect embedding via the Script
Control on Win32?

I'm saying this in utter ignorance of your problem and the API issues with
direct Python embedding; nevertheless, the Script Control can be used to host
any scripting language registered on the system, and effectively isolates
language issues from your immediate sphere of concern.  This should minimize the
interface work you have to do.

-- 

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:H2EAaJAsVCC+EwTR at jessikat.fsnet.co.uk...
> I've just come back to the embedding problem. On win32 we've tried to do
> python embedding using a dll which uses a registry key or the dll's
> location to locate the appropriate python dll. The DLL then loads up
> pointers to the required bits of the API.
>
> Some of the API is implemented as macros so it's hard to maintain python
> independence. In particular the Py_DECREF/INCREF things are not part of
> the runtime API, one can add PyString_Check and a bunch of others. It
> seems the idea of using a version agnostic interface might as well be
> thrown away. The C API seems to be a compile time only thing.
>
> It seems to be abnormal to build python as a shared library with unix
> systems. Is there a standard way to accomplish this? Should I bite the
> bullet and accept that any embedding process has to use the static lib
> and create large interface shared things?
> -- 
> Robin Becker