[C++-sig] [BPL] python::interpreter proposal

Dirk Gerrits dirk at gerrits.homeip.net
Thu Jan 2 15:36:50 CET 2003


For the python::interpreter class that has been discussed here earlier I 
propose the following interface:

interpreter::interpreter(int argc, char* argv[])

Initialize the (sub-)interpreter and set it's argument strings.

interpreter::interpreter()

Initialize the (sub-)interpreter.

interpreter::~interpreter()

Release the (sub-)interpreter.

object interpreter::run(object code_string);

Run the Python code in the string extract<std::string>(code_string) with 
this (sub-)interpreter and return the result.

object interpreter::run_file(char const* filename);

Run the Python code in the specified file with this (sub-)interpreter 
and return the result.

This should probably throw an exception if the file can't be opened.

And of course these two run_* functions should throw upon a Python 
exception.


Issues:

- A sub-interpreter has no sys.argv variable, so the first form of the 
constructor would fail. Perhaps it is possible to artificially give the 
sub-interpreter this field? In any case I don't really see the use of 
giving argv paramaters to any interpreter other than the main interpreter.

- The destructor must either fail or leak unless the Py_Finalize 'bug' 
is solved. I looked at the problem for a bit but I haven't put enough 
time in it to make the fix yet. As Dave said, the problem is not too 
hard to solve. However it is kind of tedious. I'll try to take another 
shot at it soon, but don't let that stop anyone else from making the fix. ;)

- Should there be an interface for Py_SetProgramName(char *name)?


Other notes:

- If Python has already been initialized prior to the construction of 
the python::interpreter, then the client is apparently using the C API 
in addition to BPL and Py_Finalize should not be called in the 
destructor. There has already been some discussion in another thread 
about this and other destructor/constructor implementation issues.

Any comments/improvements/etc. are greatly appreciated.

Regards,
Dirk Gerrits

PS I regret to say that I have not spent any time on improving and 
expanding the tutorial during the last two weeks. I still mean to add 
the template Jamfile for embedding and a section about exceptions. Also, 
I'd like to filter out the Python C API stuff into a short rationale for 
why one would use BPL in embedding. Then I won't have to worry about 
explaining the BPL-way *and* the C-API-way of doing everything.







More information about the Cplusplus-sig mailing list