Mailman 3 June 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

implicitly_convertible and char*
by Dusty Leary July 9, 2004

July 9, 2004

Hello, The implicitly_convertible sample at http://boost.org/libs/python/doc/v2/implicit.html#implicitly_convertible-sp… works fine for me. However, changing "int" to "char*" makes it stop working. Compiles fine, won't invoke at runtime. >From the traceback: Boost.Python.ArgumentError: Python argument types in __testmodule__.test_string(X) did not match C++ signature: test_string(char *) I am using MSVC7.1 Any info?

4 13

Boost.Python in SUSE 9.0 or SUSE 9.1?
by Chad Austin July 9, 2004

July 9, 2004

Hi all, Has anyone successfully used Boost.Python in SUSE 9.0 or SUSE 9.1? In 9.0 I had to build and install boost 1.31 from source, but 9.1 comes with a boost 1.31 package. Either way, merely #including <boost/python.hpp> causes an internal compiler error in a variety of places. Note: SUSE 9.0 uses gcc 3.3.1 (+ SUSE-specific patches?) and SUSE 9.1 uses gcc 3.3.3 (+ patches again?). If I build gcc 3.4.0 from source, Boost.Python compiles, but does not link do to incompatibilities in libstdc++. I'm going to try Boost.Python from CVS before anything else, but I thought I'd ask if anyone else has had success or failure in this area. Thanks, Chad

5 22

compile errors with embedding example from tutorial
by Faheem Mitha July 6, 2004

July 6, 2004

Dear People, When trying to compile the following code (direct from sample code in the turorial) I get these errors. I am using distutils and realise my flags may not be exactly right, but the compiler seems to be saying it cannot find the correct version of handler to use! This does not look like it has anything to do with the correct flags, though I could be wrong. I'm trying to call the interpreter from within a extension module. Is there any reason I can't do this? Thanks in advance. Faheem. building 'embed' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.3 -c embed.cc -o /tmp/temp.linux-i686-2.3/embed.o -Wl,-E embed.cc: In function `void foo()': embed.cc:35: error: no matching function for call to ` boost::python::handle<PyObject>::handle(const char[73], int, PyObject*, PyObject*)' /usr/include/boost/python/handle.hpp:129: error: candidates are: boost::python::handle<T>::handle(boost::python ::detail::borrowed_reference_t*) [with T = PyObject] /usr/include/boost/python/handle.hpp:110: error: boost::python::handle<T>::handle(const boost::python::handle<T>&) [with T = PyObject] /usr/include/boost/python/handle.hpp:205: error: boost::python::handle<T>::handle() [with T = PyObject] error: command 'gcc' failed with exit status 1 make: *** [embed.so] Error 1 make: Target `all' not remade because of errors. Compilation exited abnormally with code 2 at Mon Jun 28 00:02:00 ************************************************************************* embed.cc ************************************************************************* #include <boost/python.hpp> #include <boost/scoped_ptr.hpp> #include <python2.3/Python.h> #include <pythonrun.h> using namespace boost::python; void foo() { Py_Initialize(); handle<> main_module(borrowed( PyImport_AddModule("__main__") )); handle<> main_namespace(borrowed( PyModule_GetDict(main_module.get()) )); handle<>( PyRun_String("hello = file('hello.txt', 'w')\n" "hello.write('Hello world!')\n" "hello.close()", Py_file_input, main_namespace.get(), main_namespace.get()) ); Py_Finalize(); } BOOST_PYTHON_MODULE(embed) { def("foo",foo); } *************************************************************************

9 40

Getter/Setter as Property with Pyste
by Achim Domma July 4, 2004

July 4, 2004

Hi, I try to generate Code with Pyste. The wrapped classes have lots of getter and setter functions. The generated code looks like this: .def("borderColor", (void (Magick::Image::*)(const Magick::Color&) )&Magick::Image::borderColor) .def("borderColor", (Magick::Color (Magick::Image::*)() const)&Magick::Image::borderColor) Is there a simple way to tell Pyste to generate an add_property call for 'borderColor' instead of the two functions? regards, Achim

2 1

Re: Calling a python function from C++ (from Jeff Holle)
by Jeff Holle July 4, 2004

July 4, 2004

> > >> An underlining concern I have is error handling. When >> PyImport_ImportModule fails, a NULL pointer is returned. >> Seems like the underlining machinery in "handle<>" is intolerant of >> this. > > > >What makes you say that? > You are correct about the success in compiling your much cleaner example, and it works :-) , but has a flaw. When I hide the needed python script, the call to PyImport_ImportModule returns NULL. When this occurres, both your example and what I had created, but commented out throws something because I can catch it with "catch(...)". I don't however know how to be more specific. Any hints? Whatever it is, it doesn't inherit from "exception". If I was operating on windows, I would anticipate it was a "structured exception", or whatever Microsoft calls their propritary stuff. Don't know of the equivalent on linux though. Without the "catch (...)", the command line program exits with "Aborted".

4 7

RE: [C++-sig] Abstract classes
by Roman Yakovenko June 30, 2004

June 30, 2004

Paul wrote: > Pyste was generating constructors defs for abstract classes. > I've changed > Pyste so that it will insert no_init (and emit no > constructors) for abstract > classes. > > Is this the correct behaviour for an abstract class? > eg. > class_< Foo, boost::noncopyable>("Foo", no_init) > > This from the FAQ states this quite clearly: > http://www.python.org/cgi-bin/moinmoin/boost_2epython_2fFAQ > > * no_init means "do not try to create an instance of > that Python object, create __init__ function that throws an exception" > > * noncopyable means "do not try to register a converter > which can convert C++ return values of that class to Python". > > > > When wrapping an abstract class, it's necessary to specify both. > > However, what's confusing me is that I thought specifying > no_init would make > the following incorrect: > > class Bar(CppModule.Foo): > def __init__(self): > CppModule.Foo.__init__(self) > > Is that correct? I think this is correct. Abstract class has constructors. Roman --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004

2 1

Re: Calling a python function from C++
by Jeff Holle June 30, 2004

June 30, 2004

Dave wrote: Why struggle? This should be: object /* Returns a borrowed reference */ getPythonFunction(string moduleName,string functionName) { object _module(handle<>( PyImport_ImportModule(const_cast<char*>(moduleName.c_str())))); <<-- line 63 in Main.cpp return _module.attr(functionName.c_str()); } ------------------------------------------------------------------------ Always a good question. The code doesn't compile as presented. I added #include <boost/python/object.hpp> to my module, have completely opened the boost::python namespace. Get the error: Main.cpp:63: error: variable declaration is not allowed here If I just instanciate an empty object with its default constructor, the module compiles. An underlining concern I have is error handling. When PyImport_ImportModule fails, a NULL pointer is returned. Seems like the underlining machinery in "handle<>" is intolerant of this.

2 1

Abstract classes
by paul.bridger June 30, 2004

June 30, 2004

Pyste was generating constructors defs for abstract classes. I've changed Pyste so that it will insert no_init (and emit no constructors) for abstract classes. Is this the correct behaviour for an abstract class? eg. class_< Foo, boost::noncopyable>("Foo", no_init) This from the FAQ states this quite clearly: http://www.python.org/cgi-bin/moinmoin/boost_2epython_2fFAQ > * no_init means "do not try to create an instance of that Python object, create __init__ function that throws an exception" > * noncopyable means "do not try to register a converter which can convert C++ return values of that class to Python". > > When wrapping an abstract class, it's necessary to specify both. However, what's confusing me is that I thought specifying no_init would make the following incorrect: class Bar(CppModule.Foo): def __init__(self): CppModule.Foo.__init__(self) Is that correct?

1 0