[C++-sig] embedding: API and signals

Ingo Lütkebohle iluetkeb at gmail.com
Wed Nov 24 11:43:54 CET 2004


Hi,

I'm migrating some code from a custom
not-much-more-than-refcountin-c++ wrapper around the Python API to
boost::python, for embedding.  This works great so far, I'm especially
happy about the automatic type-conversion for stuff I already have
boost-wrappers for.  Thanks a lot for a very usefull library :)

However, a couple of things I noticed:

 * boost::python seems to keep around the Python SIGINT handler by
default.  That means, SIGINT doesn't work while in C++ code.

Q: Would it be possible to have a chaining signal handler or a simple
method to swap Pythons signal handler to SIG_DFL at some chosen
juncture points?

 * boost::python requires the user to have Python.h in its include
path.  I have one use case where this is inconvenient:  All thats
exposed in my class header is a 'handle' (PyObject*), all manipulation
is done in the .cpp.  Ideally, I would only want to include Python.h
in the .cpp so that the user of *my* class doesn't need to have
Python.h around.

Q: Could one forward declare struct PyObject in handle_fwd.hpp or the
like to work around that?

 * the boost::python::object API (and list, tuple, dict, etc) lacks
some fairly basic methods, such as Size on sequences.  I know I can do
   extract<long>(list.attr('__len__')())
but that seems a little awkward and also, I wonder what would happen
if some smarty tries to define __len__ as an attribute?

Q: The Python/C API has convenience methods, could we use them?

 * thread-safety.  I understand this is an old topic but, as far as I
understood it, current solutions are all (with patch) or nothing
(current default).  Given that the user usually knows which parts of
his code could block or are time-consuming...

Q: could this be made configurable, ala return_value_policies?

regards

Ingo



More information about the Cplusplus-sig mailing list