[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