Embedding/Extending Python in/with C++: non-static members?

AnonMail2005 at gmail.com AnonMail2005 at gmail.com
Thu Jul 19 09:43:47 EDT 2007


On Jul 16, 9:45 am, dmoore <damienlmo... at gmail.com> wrote:
> Hi Folks:
>
> I have a question about the use of static members in Python/C
> extensions. Take the simple example from the "Extending and Embedding
> the Python Interpreter" docs:
>
> A simple module method:
>
> static PyObject *
> spam_system(PyObject *self, PyObject *args)
> {
>  ...
>
> }
>
> listed in a method table:
>
> static PyMethodDef SpamMethods[] = {
>     ...
>     {"system",  spam_system, METH_VARARGS,
>      "Execute a shell command."},
>     ...
>     {NULL, NULL, 0, NULL}        /* Sentinel */
>
> };
>
> that is registered with:
>
> PyMODINIT_FUNC
> initspam(void)
> {
>     (void) Py_InitModule("spam", SpamMethods);
>
> }
>
> I have an application that embed multiple interpreters. I want to be
> able to register methods for each interpreter that access C++ state
> data relevant to that particular interpreter. In other words I want to
> be able to register non-static class members in a class like the
> following:
>
> class PythonSpamModuleInstance
> {
>     PythonSpamModuleInstance()
>     {
>         SpamMethods[0]={"system",  spam_system, METH_VARARGS,"Execute
> a shell command."};
>         SpamMethods[1]={NULL, NULL, 0, NULL};
>         PyObject *spammodule=Py_InitModule("spam", SpamMethods); //
> Needs an INCREF call?
>     }
>     ~PythonSpamModuleInstance()
>     {
>         PyObject_Del("spam", SpamMethods);
>     }
>     PyObject *spam_system(PyObject *self, PyObject *args)
>     {
>          // accesses non-static data in this class
>     }
>     PyMethodDef SpamMethods[2];
>     PyObject *spammodule;
>     // Other data specific to this instance of the module
>
> };
>
> The idea is that each time my app launches an embedded Interpreter it
> will create an accompanying instance of PythonSpamModuleInstance that
> allows the Interpreter to call the registered non-static C++ member
> function spam_system. Calls to that member function will also affect
> state information.
>
> So the questions: will this work? In particular, will the use of non-
> static member functions cause problems? Is there a better way of
> creating extension modules for multiple embedded interpreters? If I am
> forced to use static methods, how do i figure out which interpreter is
> calling them?
test posting.




More information about the Python-list mailing list