DLL/Embeded interpreter wierdness

[David Bolen]

Courageous <jkraska at san.rr.com> writes:

> I don't really know what you mean here. This module in question is
> actually masquerading as a package, so extended import commands look
> more like...
> 
> from lramm import task

Well, that doesn't really need a package to function, just a working
module.  Since this is a DLL we're talking about, I'm assuming you
just call one of the Py_InitModule calls in your initxxx routine,
right?  Or are you doing something more when you say "masquerading as
a package"?

> ...and so on. So the explicit initialization is required from the embedded
> code, which is otherwise unrestricted Python.

That's fine - in my suggestion, under the embedded environment,
"lramm" will already exist as a module, so this from will simply
reference that module and copy references to the specified objects
into the local namespace.

> I seem to have some sort of knowledge failure here. Outside of the
> usual init[blah] hookups, what does one do to "automatically define
> my module internally"?

Basically just run the same sort of code you currently have in the
init[blah] function, but without waiting for Python to call your
init[blah] function.  You do it before transferring control to the
embedded interpreter to execute the embedded script.

For example, in an embedded app of mine, here's where I initialize
Python:

    #define INSITEM(name,value) \
       intobj = PyInt_FromLong((value) & 0xFF); \
       PyDict_SetItemString(dictobj,name,intobj); \
       Py_XDECREF(intobj)

    (...)

    PyObject *modobj, *dictobj, *intobj;

    Py_Initialize();
    PyEval_InitThreads();
    ecnaPy_RcvThreadState = PyThreadState_New(PyThreadState_Get()->interp);

    PyImport_AddModule("ecna");
    modobj = Py_InitModule("ecna",ecnaPy_Methods);

    /* Add in definitions for the protocol defines into dictionary */
    dictobj = PyModule_GetDict(modobj);
    INSITEM("dSrvHReset",dSrvHReset);
    INSITEM("dSrvInit",dSrvInit);
    INSITEM("dSrvUSetup",dSrvUSetup);
    INSITEM("dSrvUReset",dSrvUReset);

    (...)

    /* Automatically import our own module */
    PyRun_SimpleString("import ecna");

    (...)

    /* Execute script */
    PyRun_SimpleFile(OptScriptFile,OptScriptName);


(I use the embedded interpreter from multiple threads thus the
acquisition of an extra thread state).

This defines "ecna" as a built-in module to the embedded script (and
also automatically imports it on behalf of the executing script).

The script could just as easily have used either:

    import enca

or

    from ecna import dSrvHReset # For example

And the only real difference between this and what I would have used
if this were strictly an extension module is that as an extension
module I wouldn't need to initialize the interpreter.  So its not too
hard to build a single initialization function that is called
post-interpreter initialization in the embedded case, or just directly
from your init[blah] function in the extension case.

Hoping this makes things clearer rather than more muddy...

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/