Mmmkay, looks like I found a dirty little workaround:
I put the C++ functions, I want to expose into a dummy class:
class Dummy
{
int f1(str arg1, ...
void f2(tuple arg1, ...
}
And then create a bpy object from it:
object tmp = class_<Dummy>("dummy")
.def("f1", &Dummy::f1)
.def("f2", &Dummy::f2);
Since I don't want to have this class in Python, I now add the methods
to the namespace instead:
global["my_mod"].attr("__dict__")["f1"] = tmp.attr("__dict__")["f1"];
global["my_mod"].attr("__dict__")["f2"] = tmp.attr("__dict__")["f2"];
Doing so, I end up with callable functions f1 and f2 in my_mod's
namespace which act as if they where simple functions outside of any
class, but benefit from boost's functionalities.
The only undesirable side effect I spotted is tracebacks exposing the
dummy class name:
Boost.Python.ArgumentError: Python argument types in
dummy.f1(str, str)
did not match C++ signature:
Message(boost::python::str, boost::python::str, boost::python::str)
Note to anyone who's about to reproduce my solution: The dummy class
mustn't have a staticmethod("f1") call, otherwise you end up with a
non-callable "staticmethod" object f1 in namespace.
Any comments welcome.
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
