embedded python and interpreter threads

Charlie DeTar chazen at gmail.com
Tue Dec 7 00:02:14 EST 2004


So, I have an amazing, functioning foobar class that embeds python. 
Only trouble is, I want to be able to have multiple foobar objects at 
once, each with their own interpreters, stdouts, and stderrs.

My initialization of the python interpreter in the class "x" is as follows:
[snip]
	if (!Py_IsInitialized()) {
		PyEval_InitThreads();
		Py_Initialize();
	}	
	
	// Start and switch to a new interpreter thread.
	x->thread = Py_NewInterpreter();

	// initialize the module 'logMethods', defined elsewhere,
	// which contains my stdout and stderr definitions
	Py_InitModule("log", logMethods);
	
	// overwrite Python's stdout and stderr
	PyRun_SimpleString(
		"import log\n"
		"import sys\n"
		"class StdoutCatcher:\n"
		"\tdef write(self, str):\n"
		"\t\t.CaptureStdout(str)\n"
		"class StderrCatcher:\n"
		"\tdef write(self, str):\n"
		"\t\t.CaptureStderr(str)\n"
		"sys.stdout = StdoutCatcher()\n"
		"sys.stderr = StderrCatcher()\n");
	
	PyEval_ReleaseThread(x->thread);
[snip]

Everything seems to work as expected - each object seems to have its own 
interpreter (if I evaluate "tree = 'a larch'" in one of them, 'tree' is 
not thusly defined in the others).  Since I store the threadstate as a 
property of the object, I can easily juggle the interpreter lock between 
objects when evaluating python code.  However, the last foobar object to 
be instantiated collects the stdout and stderr of all the other objects 
(as though the stdout and stderr definitions were shared over all the 
objects).  This seems strange, as the docs say that if I start a 
"Py_NewInterpreter()" I get new copies of all the modules, particuarly 
'sys', and explicitly 'stdout' and 'stderr'.

I thought of the possibility that the 'logMethods' structure which 
includes my versions of stdout and stderr might be behaving statically. 
  But I didn't define it as static...  I am new to C, so there might be 
something basic I am missing.  Any suggestions or ideas?

Thanks,
Charlie DeTar



More information about the Python-list mailing list