[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