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

[David Abrahams]

Ingo Lütkebohle <iluetkeb at gmail.com> writes:

> 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?

Which chosen juncture points?
Can you supply a patch?

>  * 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.

Understood.

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

I seriously doubt it, because of the many inline functions in
Boost.Python.  A rewrite of Boost.Python / Luabind called
Boost.Langbinding is in the works (but on the back burner) that would
allow you to do all wrapping without exposure to Python.h, but
unfortunately it's still nascent.

>  * 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?

Sure, please submit a patch :^).

>  * 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?

Ditto.

Sorry, I wish I had more time to work on this project...

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com