Mailman 3 April 2004 - Cplusplus-sig

RE: [C++-sig] Re: Wrapper for exception translation
by Gottfried.Ganssauge＠HAUFE.DE Dec. 13, 2004

Dec. 13, 2004

> > ... > >> > >> > Currently, in order to wrap user defined exceptions you need to > >> > > >> > - allocate a python exception using PyErr_NewException > >> > >> Well, no. I don't see any call to PyErr_NewException in > >> libs/python/test/exception_translator.cpp > > > > Right, you don't need to if you are content with RuntimeError > > exceptions. > > or any other pre-packaged exception type provided by Python. > > > My objective was another one: I wanted to create module exceptions > > that are derived from the python "Exception" class. > >> > >> > This function needs to be parametrized using a specific naming > >> > convention > >> > >> It's not clear to me what you're referring to. Are you > sure you mean > >> "naming convention"? > > Yes. > > From the documentation to PyErr_NewException: > > > > ... The __module__ attribute of the new class is set to > the first part > > (up to the last dot) of the name argument, and the > class name is set to > > the last part (after the last dot). > > ...yeah, that's a naming convention, but I don't see how that affects > the parameterization of any function. It is enforced by PyErr_NewException, so you must follow this convention. On the hand I don't think that any user of boost.python is aware of that convention, so I wanted to codify it within my facility. ... > > What I wanted to achieve was the following: > > Create an instance of a translated_exception_handler<> t > which will be > > registered with the library by calling > > register_exception_translator<>(). > > Sorry to be difficult, but I'm going to contradict you. You didn't > want any of that. What you wanted was to create a new Python > exception type in the module which would correspond to a particular > C++ exception type and would be raised at the boundary with Python > whenever a wrapped function threw the C++ exception. Right? Right. I actually described the way to do it within the current library design. > > > Normally t would be destructed by the end of exception_<>() thereby > > leaving a registration to a non-existing translator - very bad > > karma. > > I don't understand any of this. All you have to pass to > register_exception_translator is a function pointer, and functions > live forever. So where's the lifetime issue? A pointer to a function which has access to python exception instance e. As I didn't want to create separate entities I chose to supply a functor instead which has e as a member variable. > > > Because I didn't like to have an additional container for all > > translated_exception_handler<> instances, I chose to store t within > > e's class dictionary. At that moment it seemed to be the easiest > > way to create a wrapper class using class_<> instead of making a > > true python class by hand (and it even works!). You are right, it > > is way too complex, I will change it to the mechanism I used in > > opaque_pointer_converter. > > I don't know what that is, but before you consider doing something > which is again too complex, please consider: > > template <class E> > struct translate_exception > { > static char const* msg; This would need to be defined somewhere. > static object python_exception_type; ... and this would need to be defined somewhere as well. > > static void handler(E const&) > { > PyErr_SetString(python_exception_type.ptr(), msg.c_str()); > }; > > translate_exception(char const* python_exception_name, > char const* msg_) > { > // need fancier name manipulation here > python_exception_type > = object( > handle<>(PyErr_NewException(name))); > msg = msg_; > register_exception_translator<E>(handler); > } > }; > > > Simple. Yes. ... > > I'll make a redesign ... At times you don't see the forrest, just trees ... I think this time I have a simple facility which is also easy to use (no macros). It could be even simpler with a completely different design but frankly - I have no clue how to implement that: We would need a way to somehow derive (in the python sense) a class_<> from PyExc_Exception (the type of the python Exception class) or any other python class (PyErr_NewException() has a base parameter, which could be used for that). At the same time an exception_translator should be registered for that class_<> which uses PyErr_SetObject() to raise a copy of the exception caught. This would allow us to have true Python exceptions in a pythonic sense directly wrapped around the corresponding C++ exception. > > Thnx for your feedback. > > Cool! Looking forward to it. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com Cheers, Gottfried

3 7

Boost Python and Intel C++ 7.1 windows
by Xavier WARIN(Compte LOCAL) - I23 Aug. 16, 2004

Aug. 16, 2004

Hi, While compiling with Intel C++ 7.1 Boost Python , i get this kind of error on class.cpp and a lot of other Boost Python files : C:\boost-1.30.2\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral<unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) I think that there must be a define that i missed somewhere ! I don't find it Any idea ? Thank you Xavier Warin

2 2

manage_new_object using release() instead of delete
by Eric May 11, 2004

May 11, 2004

Hi all, I am new to Boost.Python, but so far have been extremely impressed. I was wondering if there was a version of the manage_new_object return policy that called a release() function on an interface rather than calling delete? I am trying to wrap a chunk of code that works like this: class Interface { public: virtual void doSomething() = 0; virtual void release() = 0; protected: virtual ~Interface() {} }; Interface * SomeFactory( ... ); Now, if Interface was a normal data struct, I'd just use manage_new_object as the policy for SomeFactory, but that wouldn't work here because the destructor is protected. Is there some way to have the release function called at the end of the Interface pointer's life in python? And is it further possible to have the release() function not be callable from python (to protect against double-deletes)? Thanks!

2 7

using map_indexing_suite: make_tuple ambiguous?
by Dave Berton May 4, 2004

May 4, 2004

I am trying to wrap a std::map<> using the map_indexing_suite<>, however I am getting 'call of overloaded make_tuple() is ambiguous'. The simplest case to reproduce this error is to modify boost/libs/python/test/map_indexing_suite.cpp, and add the following small bit of code: // Compile check only... class_<std::map<std::string, boost::shared_ptr<X> > >("TestMap") .def(map_indexing_suite<std::map<std::string, boost::shared_ptr<X> > >()) ; I don't see why this is any different than any of the other tests in that file. But for some reason (using Boost 1.31 on Debian stable, gcc 3.3), I get the following output: [db@ivo ~/src/boost/libs/python/test] bjam ...patience... ...found 5307 targets... ...updating 2 targets... gcc-C++-action ../../../bin/boost/libs/python/test/map_indexing_suite_ext.so/gcc/debug/shared-linkable-true/map_indexing_suite.o /home/db/src/boost_1_31_0/boost/python/suite/indexing/map_indexing_suite.hpp: In static member function `static boost::python::api::object boost::python::map_indexing_suite<Container, NoProxy, DerivedPolicies>::print_elem(typename Container::value_type&) [with Container = std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, bool NoProxy = false, DerivedPolicies = boost::python::detail::final_map_derived_policies<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, false>]': /home/db/src/boost_1_31_0/boost/python/suite/indexing/map_indexing_suite.hpp:85: instantiated from `static void boost::python::map_indexing_suite<Container, NoProxy, DerivedPolicies>::extension_def(Class&) [with Class = boost::python::class_<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, Container = std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, bool NoProxy = false, DerivedPolicies = boost::python::detail::final_map_derived_policies<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, false>]' /home/db/src/boost_1_31_0/boost/python/suite/indexing/indexing_suite.hpp:188: instantiated from `void boost::python::indexing_suite<Container, DerivedPolicies, NoProxy, NoSlice, Data, Index, Key>::visit(Class&) const [with Class = boost::python::class_<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, Container = std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, DerivedPolicies = boost::python::detail::final_map_derived_policies<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, false>, bool NoProxy = false, bool NoSlice = true, Data = boost::shared_ptr<X>, Index = std::string, Key = std::string]' /home/db/src/boost_1_31_0/boost/python/def_visitor.hpp:32: instantiated from `static void boost::python::def_visitor_access::visit(const V&, classT&) [with V = boost::python::def_visitor<boost::python::indexing_suite<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, boost::python::detail::final_map_derived_policies<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, false>, false, true, boost::shared_ptr<X>, std::string, std::string> >, classT = boost::python::class_<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>]' /home/db/src/boost_1_31_0/boost/python/def_visitor.hpp:68: instantiated from `void boost::python::def_visitor<DerivedVisitor>::visit(classT&) const [with classT = boost::python::class_<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, DerivedVisitor = boost::python::indexing_suite<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, boost::python::detail::final_map_derived_policies<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, false>, false, true, boost::shared_ptr<X>, std::string, std::string>]' /home/db/src/boost_1_31_0/boost/python/class.hpp:294: instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def(const boost::python::def_visitor<Derived>&) [with Derived = boost::python::indexing_suite<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, boost::python::detail::final_map_derived_policies<std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, false>, false, true, boost::shared_ptr<X>, std::string, std::string>, T = std::map<std::string, boost::shared_ptr<X>, std::less<std::string>, std::allocator<std::pair<const std::string, boost::shared_ptr<X> > > >, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' ../../../libs/python/test/map_indexing_suite.cpp:50: instantiated from here /home/db/src/boost_1_31_0/boost/python/suite/indexing/map_indexing_suite.hpp:95: error: call of overloaded `make_tuple(const std::string&, const boost::shared_ptr<X>&)' is ambiguous /home/db/src/boost_1_31_0/boost/python/detail/make_tuple.hpp:24: error: candidates are: boost::python::tuple boost::python::make_tuple(const A0&, const A1&) [with A0 = std::string, A1 = boost::shared_ptr<X>] /home/db/src/boost_1_31_0/boost/tuple/detail/tuple_basic.hpp:717: error: typename boost::tuples::detail::make_tuple_mapper<T0, T1, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type boost::tuples::make_tuple(const T0&, const T1&) [with T0 = std::string, T1 = boost::shared_ptr<X>] Any ideas? db

3 4

boost.python + mingw + msvc python
by Daniel Holth May 1, 2004

May 1, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Have any of you used a mingw compiled Boost.Python to compile an extension for MSVC python (the standard python.org python)? I've had a pretty straightforwards experience using ming to compile Boost.Python (on an XP box, sadly NOT cross compiled from a Linux machine) making gcc libraries for various dlls, and I can compile the extension itself. Unfortunately when I try to import the extension I get a vague sort of 'dll not found' error. I know this is vague, I just would like to know if anyone has succeeded in compiling a working Python+Boost.Python extension this way. I'm trying to wrap ogg, vorbis and theora. (http://dingoskidneys.com/oggpy/) Thanks, Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAc3mOVh4W2pVfoMsRAo8UAKCFAmvreyuAe2Tw0kbo/NYY+tqYCgCgj8SH ltTCEyTB4cAhaouFDOMeo/g= =Zilu -----END PGP SIGNATURE-----

3 2

__repr__ and string values
by Dave Berton May 1, 2004

May 1, 2004

Consider a class which can represent itself as a string: class Foo { public: std::string toString() { return "foo"; } }; This is wrapped thus: class_< Foo, boost::shared_ptr<Foo> >("Foo", "The Foo class" ) .def(init< >()) .def("toString", &Foo::toString ) .def("__repr__", &Foo::toString ) ; When imported into python, I get different return values calling Foo::toString() compared to when I let python get the return value implicitly: >>> from foo_ext import * >>> f = Foo() >>> f.toString() 'foo' >>> f foo Why does the explicit call to Foo::toString() return a properly quoted string while the implicit call invoked by python does not? How should I wrap Foo such that both ways of getting the string representation return the same thing (a quoted string)? db

5 7

injected constructor with a docstring?
by Nick Rasmussen April 30, 2004

April 30, 2004

I'm creating an injected constructor for one of my classes, but can't seem to add a docstring to it in the .def: #include <boost/python.hpp> #include <boost/python/make_constructor.hpp> using namespace boost::python; class C { public: C(int i, int j, int k) {} }; C * make_C() { return new C(0,0,0); } BOOST_PYTHON_MODULE(test_boost) { class_<C>("C", "C docstring", init<int,int,int>("doc: C(i,j,ij)")) .def("__init__",make_constructor(make_C),"doc: C()") ; } results in (using gcc-3.3.2): XXX/boost/python/object_core.hpp: In member function `void boost::python::api::object_operators<U>::visit(ClassT&, const char*, const boost::python::detail::def_helper<DocStringT, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>&) const [with ClassT = boost::python::class_<C, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, DocStringT = char[9], U = boost::python::api::object]': XXX/boost/python/def_visitor.hpp:44: instantiated from `static void boost::python::def_visitor_access::visit(const V&, classT&, const char*, const OptionalArgs&) [with V = boost::python::def_visitor<boost::python::api::object>, classT = boost::python::class_<C, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, OptionalArgs = boost::python::detail::def_helper<char[9], boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>]' XXX/boost/python/def_visitor.hpp:75: instantiated from `void boost::python::def_visitor<DerivedVisitor>::visit(classT&, const char*, const OptionalArgs&) const [with classT = boost::python::class_<C, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, OptionalArgs = boost::python::detail::def_helper<char[9], boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, DerivedVisitor = boost::python::api::object]' XXX/boost/python/class.hpp:488: instantiated from `void boost::python::class_<T, X1, X2, X3>::def_impl(const char*, LeafVisitor, const Helper&, const boost::python::def_visitor<Visitor>*) [with Helper = boost::python::detail::def_helper<char[9], boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, LeafVisitor = boost::python::api::object, Visitor = boost::python::api::object, T = C, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' XXX/boost/python/class.hpp:571: instantiated from `void boost::python::class_<T, X1, X2, X3>::def_maybe_overloads(const char*, Fn, const A1&, ...) [with Fn = boost::python::api::object, A1 = char[9], T = C, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' test_boost.C:304: instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def(const char*, A1, const A2&) [with A1 = boost::python::api::object, A2 = char[9], T = C, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' test_boost.C:16: instantiated from here XXX/boost/python/object_core.hpp:181: error: invalid application of `sizeof' to an incomplete type removing the "doc: C()" string allows it to compile. I know that I can add it manually later, but is there a way to do it in the .def? -nick

2 1

bjam rules for building embedded applications
by Graeme Lufkin April 30, 2004

April 30, 2004

Looking at the new(ish) example/Jamfile, I've (I think) figured out the recommended way to build Boost.Python extensions. Extrapolating the idea, I've created a similar Jam template for embedding applications. Please critique it, to verify that I'm correctly understanding how bjam works in this instance. If members of the list agree with my understanding, I can update and submit diffs of the tutorial, which still uses old-style Jamfiles for both extensions and embedding. To build an extension, you use the extension rule and include the extension template (<template>@boost/libs/python/build/extension, where @boost is defined in the Jamrules file to point at the boost source tree) in the list of sources. This will build two shared libraries in the bin directory, libboost_python.so and your extension. The template checks for updates to the Boost.Python source and automatically rebuilds. To build an embedded application, we will use the exe rule and an embedding template defined below. This template should get added to libs/python/build/Jamfile in the Boost sources. template embedded : <lib>boost_python #embedded needs static library, not dynamic : <sysinclude>../../.. #boost headers $(BOOST_PYTHON_V2_PROPERTIES) #Python include/linking dirs <find-library>$(PYTHON_EMBEDDED_LIBRARY) #libpython <find-library>pthread #needed for my system ; This template is used exactly as the extension template, for example in the Jamfile: exe embedded_test : embedded_test.cpp <template>@boost/libs/python/build/embedded ; This will build libboost_python.a (a static library) and your executable, again checking for updates in the Boost.Python source tree. Okay, some notes: I needed to add the <find-library>pthread on my system (RH9, gcc 3.2.2, Python 2.2.2). If this isn't only observed on my system, it should probably be added to the definition of $(PYTHON_EMBEDDED_LIBRARY) in tools/build/v1/python.jam The tutorial (both the extending and embedding examples) uses Jamfiles with lots of other stuff that (at best) doesn't appear to be necessary and (at medium) is confusing to the reader and (at worst) doesn't work anymore. I volunteer to update the tutorial on this point. Are diffs to the CVS version submitted to this list the appropriate way to do this? Some questions: If I've got several separate programs (either extending, or embedding) using this technique, then each one has their own version of libboost_python.[a|so] which seems rather wasteful. Is there a recommended way to use a libboost_python.[a|so] in a fixed location? That is, please provide a Jamfile entry to do this. When building all of boost (that is, running bjam in $(BOOST_ROOT) ) it makes several versions (compiler/threading/debug) of the libraries (not just Boost.Python) and (optionally) installs them to a given location. Could the extension and embedded templates be reworked to link against these versions of libboost_python, so that (as requested above) there is only one source of the library to link against? How might this be done? Thanks very much for your patience reading this long message. -- - Graeme Lufkin gwl(a)u.washington.edu "This sentence contains exactly threee erors."

2 1

lost sys.stderr
by sachin kesarkar April 30, 2004

April 30, 2004

hello, i tried to run Mozpython 0.1.1 over RH 9.0 with Python 2.3.3 and Mozilla 1.6, the compilation runs successfully but when i try to run Python scripts in Mozilla it gives me error as " lost sys.stderr" ny help is welcome. Sachin --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs

1 0

Fwd: Help - Callbacks
by Richard M Norton April 30, 2004

April 30, 2004

Hello, Im having difficulties concerning using callbacks that have been extended in python. Im using the windows video API DirectShow to play video to a screen through a transform method. The problem occurs when the Transform method is called from an object extended in python as a callback, not when called explicitly. How do I represent this functionality and prevent the python interpreter from crashing? I do not think the problem in this case is from the live times of the objects, but I may be wrong. Is using boosts function and bind features a solution, and if so how? Many Thanks, Richard // Cut down version of the C++ code class Callback { virtual void Transform() = 0; } class Player { Player(Callback *); void Play(); // Play the video to the screen, returns allowing video to continue play } class Callback_Wrap : public Callback { Callback_Wrap(PyObject *obj) : self(obj) {} virtual Transform() {call_method<void>(self, Transform);} PyObject *self; } BOOST_PYTHON_MODULE(MyVideo) { class_<Callback, boost::noncopyable, boost::shared_ptr<Callback_Wrap> >(Callback) .def(Transform, &Callback::Transform) ; class_<Player>(Player, init<Calback *>()) .def(Play, &Player::Play) ; } # Example python use from MyVideo import * class My_Callback(Callback): def Transform(self): print Hello, My_Callback here! a = My_Callback() b = Player(a) a.Play()

2 1