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

shared_ptr<Object>
by John Meinel Oct. 31, 2004

Oct. 31, 2004

I found an old post on how to handle handing around shared_ptr<Object> instead of Object. http://mail.python.org/pipermail/c++-sig/2004-August/007873.html However, I don't know how to do it when you have a virtual object that you want to allow inheritance from in Python. Attached is a sample version of what I'm doing. Basically, I have a base class which allows introspection into the type. This gets overridden my a virtual child, which provides some functionality. And then finally you have private grand-children which actually implement this functionality. So what goes wrong with this situation: 1) If I pass no_init to a pure-virtual object with a wrapper, I cannot inherit from it in Python. because I cannot call __init__ to create the C++ object. And if I don't call __init__, then when a function wants my inherited class, it fails with "did not match C++ signature" 2) Without no_init, it will compile, but I can directly create an object of that type, which will cause "unidentifiable C++ exception" when you try to call the function. I assume this is because it is calling the wrapper function overload, which tries to access an invalid member function. I can live with this, but I would have really liked the safety of no_init 3) If I add shared_ptr<mine> to the class_<> definition, I get "too many template parameters" error. If I replace the mine_w with shared_ptr<mine> then it will allow me to return a shared_ptr, but not inherit the C++ object in python. If I try to do shared_ptr<mine_w>, then I still cannot create a shared_ptr<mine>. 4) In my base class, I have whoami() as virtual. I override it in mine which works fine. But I cannot override it again, without adding a re-definition of "whoami". This is probably un-avoidable, especially since I need to create a default-overload. I also saw this post: http://mail.python.org/pipermail/c++-sig/2004-October/008157.html Which has stuff like "get_override" and "public wrapper<>". Is this a better way to do the python wrapping. It's not in the tutorial, and the documentation in general seems pretty weak. I also didn't find it in the documentation. http://www.boost.org/libs/python/doc/v2/reference.html Thanks for your help. John =:-> // I realize including boost/python.hpp will get all of this // but I've found it slows down compile times quite a bit #include <boost/noncopyable.hpp> #include <boost/shared_ptr.hpp> #include <boost/python/module.hpp> #include <boost/python/class.hpp> #include <boost/python/def.hpp> #include <boost/python/call_method.hpp> #include <boost/python/manage_new_object.hpp> // This is the basic heirarchy class parent : boost::noncopyable { public: virtual std::string whoami() const = 0; }; class mine : public parent { public: virtual std::string whoami() const { return "mine"; } virtual bool func1(int a) const = 0; }; class child : public mine { public: virtual bool func1(int a) const { return a > 10; } }; boost::shared_ptr<mine> getMine() { return boost::shared_ptr<mine>(new child); } mine* getRawMine() { return new child; } std::string useParent(const parent& p) { std::string s(p.whoami()); return s; } std::string useMine(const mine& m, int a) { std::string s(m.whoami()); if(m.func1(a)) { s += " true"; } else { s += " false"; } return s; } // Now on to the boost::python wrappers using namespace boost::python; class parent_w: public parent { public: PyObject *self; parent_w(PyObject *_self) : self(_self) {} virtual std::string whoami() const { return call_method<std::string>(self, "whoami"); } }; class mine_w : public mine { public: PyObject *self; mine_w(PyObject *_self) : self(_self) {} virtual bool func1(int a) const { return call_method<bool>(self, "func1", a); } // Without this, whoami cannot be overloaded from a "mine" object. virtual std::string whoami() const { return call_method<std::string>(self, "whoami"); } std::string d_whoami() const { return mine::whoami(); } }; void exportMine() { class_<parent, parent_w, boost::noncopyable>("parent", no_init) .def("whoami", &parent::whoami) ; class_<mine, mine_w, bases<parent>, boost::noncopyable>("mine") .def("func1", &mine::func1) .def("whoami", &mine::whoami, &mine_w::d_whoami) ; def("getMine", &getMine); def("getRawMine", &getRawMine, return_value_policy<manage_new_object>()); def("useParent", &useParent); def("useMine", &useMine); } BOOST_PYTHON_MODULE(test_shared_ptr) { exportMine(); } // vim: ts=4 sw=4 noexpandtab autoindent smartindent // arch-tag: 5bc43bf0-c5e7-49fe-ba4d-93550f721cbb #!/usr/bin/env python """\ This just tests my inheritance scheme. """ import test_shared_ptr as t class python_parent(t.parent): def __init__(self): try: # This yields an exception because t.parent is "no_init" t.parent.__init__(self) except Exception, e: print "Error: %s" % e def whoami(self): return "python_parent" p = python_parent() try: #This fails because you cannot "init" the C++ portion of the object print "useParent: %s == python_parent" % t.useParent(p) except Exception, e: print "Error: %s" % e # This succeeds without the no_init, as long as you have the mine_w class m = t.mine() try: #This fails with an unidentifyable c++ error, because func1() has not # been properly defined. It is pure virtual in mine, and is designed to # call the python function in mine_w() print "useMine(m, 11): %s => should fail" % t.useMine(m, 11) except Exception, e: print "Error: %s" % e # This works because mine has overridden whoami() even though the object # isn't really valid print "useParent: %s == mine" % t.useParent(m) class python_mine(t.mine): def __init__(self): t.mine.__init__(self) def func1(self, a): return a > 20 def whoami(self): return "python_mine" try: # This always fails m = t.getMine() except Exception, e: print "Error: %s" % e m = t.getRawMine() print "useParent: %s == mine" % t.useParent(m) print "useMine(m,11): %s == mine true" % t.useMine(m, 11) m = python_mine() print "useParent: %s == python_mine" % t.useParent(m) print "useMine(m,11): %s == python_mine false" % t.useMine(m, 11) # vim: ts=4 sw=4 noexpandtab autoindent smartindent # arch-tag: 7c8c4f26-336c-49d5-a0c8-8190feb8f4c2

2 3

Re: [C++-sig] Re: const_argument test failures
by Aleksey Gurtovoy Oct. 24, 2004

Oct. 24, 2004

David Abrahams writes: >>> This compiler bug should have been worked around on >>> every platform that has partial specialization >> >> Definitely possible, but then all platforms that support partial >> specialization don't have a problem _compiling_ the code. I'm not >> sure how run-time failures come into picture here. > > The type of the argument is translated into a typeid, and type > converters are registered against a typeid. If the type of the > argument is wrong, it won't find the right registered converter. Got it. > >>> (the test passes for me with vc7.1), >> >> That's because the bug was fixed in the compiler. > > I don't think so. It used to fail on vc7.1 IIUC. I certainly ran > the test, had it fail, applied a workaround, and had the test pass on > some compiler. We are talking about slightly different bugs here. On MSVC 6.5 the following simply doesn't compile (bug #1): template< typename T > void f(void (*)(T)); void g(int const); int main() { f(g); } On VC 7 and higher it does, but T is deduced as 'int const' (bug #2). > >>> and it can be made to work on VC6/7 with >>> >>> BOOST_TT_BROKEN_COMPILER_SPEC( object ) >> >> I don't see how this one would help, though. > > It allows the workaround, which involves remove_cv, to work. ... taking care of the run-time failure. Got it. I was saying that it won't help to get 'get_signature' compile on MSVC 6.5. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

re: How can I use boost::python and Python API at the same time
by ???? Oct. 22, 2004

Oct. 22, 2004

Hi, I have allready complied boost::python and I have four lib named boost_python_pydebug.lib, boost_python_debug.lib, boost_python.lib and libboost_python_debug.lib. If I use boost::python only and link boost_python_debug.lib, it's all fine. And I checked up the application need boost_python_debug.dll and python22.dll. When I use python API in this same code, then the python.h will be include, so it link the python22_d.lib in the pyconfig.h automatic. It means the application will be need python22_d.dll, OMG!!! If my poor application running, it will crash when I get the __main__ dict, because boost::python use python22.dll but python API use python22_d.dll, python initialize twice... oops~ sorry for my poor english!

1 0

pickling new-style classes object
by Dmitri Mouromtsev Oct. 20, 2004

Oct. 20, 2004

Hello All, Is it possible to customize pickling for class objects? or these are pickled only by name using default implementation. I need to save and restore custom class definition in different Python sessions. For example: class Prototype(type): def __init__(cls, name, bases, dict): super(Prototype, cls).__init__(name, bases, dict) class C(object): __metaclass__ = Prototype def __init__(self, name): self.__name__ = name If I define new class class New(C): pass New.a = 35 New.b = 'string' and new instance of 'New': x = New('New') And trying to save 'New' and 'x': file = open('pickle_New.txt', 'w') dump(New, file) file = open('pickle_x.txt', 'w') dump(x, file) I have only 'x' state saved. __getstate__ and __setstate__ are not called for class instances(New). What is the problem? Is there another way to resolve this problem? Thanks. Dmitri

1 0

const_argument test failures
by Aleksey Gurtovoy Oct. 20, 2004

Oct. 20, 2004

The comment in the test says: * The purpose of this test is to determine if a function can be called from * Python with a const value type as an argument, and whether or not the * presence of a prototype without the cv-qualifier will work around the * compiler's bug. So, OK, the first part of it fails on MSVC < 7.1, naturally, due to the same bug that makes the following to fail: template< typename T > void f(void (*)(T)); void g(int const); int main() { f(g); // error C2664: 'f' : cannot convert parameter 1 from // 'void (const int)' to 'void (__cdecl *)(int)' return 0; } The second part of the test "passes", but of course we'll never see it in the reports. So, the question is: what exactly was the original plan for this in terms of its presence in the regression reports? Right now the failures represented by yellow cells, and I'd like to see them cleared up, whether it's done through "explicit-failures-markup.xml" or through appropriate #ifdef-s in the file itself. -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Problem With Calling Methods on Python Subclasses from C++
by Mark Rowe Oct. 18, 2004

Oct. 18, 2004

Hi, I am working on wrapping a C++ library using Boost::Python but have run into a small problem with polymorphic behaviour. Basically, I have four classes exposed to Python - MainClass, ErrorHandler, Error and AnError. AnError derives from Error. When ErrorHandler is subclassed from Python and the handleError method of an instance of the Python subclass is called from C++ with an AnError instance as an argument, the argument arrives as an Error type. I realise that this description is relatively confusing, so I have attached the C++ code and a failing Python unittest that demonstrates the problem I am encountering. I hope that someone can clear this issue up for me. Regards, Mark Rowe <http://bdash.net.nz/>

2 2

Re: C++-sig Digest, Vol 15, Issue 9
by 千里马肝 Oct. 16, 2004

Oct. 16, 2004

c++-sig-request,您好！ I have allready complied boost::python and I have four lib named boost_python_pydebug.lib, boost_python_debug.lib, boost_python.lib and libboost_python_debug.lib. If I use boost::python only and link boost_python_debug.lib, it's all fine. And I checked up the application need boost_python_debug.dll and python22.dll. When I use python API in this same code, then the python.h will be include, so it link the python22_d.lib in the pyconfig.h automatic. It means the application will be need python22_d.dll, OMG!!! If my poor application running, it will crash when I get the __main__ dict, because boost::python use python22.dll but python API use python22_d.dll, python initialize twice... oops~ Thanks for help , David Abrahams! >Send C++-sig mailing list submissions to > c++-sig(a)python.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/c++-sig >or, via email, send a message with subject or body 'help' to > c++-sig-request(a)python.org > >You can reach the person managing the list at > c++-sig-owner(a)python.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of C++-sig digest..." > > >Today's Topics: > > 1. Re: How can I use boost::python and Python API at the same > time (David Abrahams) > 2. Re: Embedding python and sigint (David Abrahams) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 14 Oct 2004 10:09:19 -0400 >From: David Abrahams <dave(a)boost-consulting.com> >Subject: [C++-sig] Re: How can I use boost::python and Python API at > the same time >To: c++-sig(a)python.org >Message-ID: <u1xg1v1bk.fsf(a)boost-consulting.com> >Content-Type: text/plain; charset=gb2312 > >"千里马肝" <tlovexyj(a)21cn.com> writes: > >> Hi, >> How can I use boost::python and Python API at the same time? > >Just use them (?) There's nothing to it. You can find numerous >examples in the libs/python/test subdirectory of your Boost CVS tree >or in http://www.boost.org/libs/python/test/. > >> So, Which lib is the right lib I must link? It's >> boost_python_debug.lib or boost_python_pydebug.lib? Thanks for >> reply~ > >http://www.boost.org/libs/python/doc/building.html#variants should >answer your question. If not, please ask. > >-- >Dave Abrahams >Boost Consulting >http://www.boost-consulting.com > > > >------------------------------ > >Message: 2 >Date: Thu, 14 Oct 2004 10:10:04 -0400 >From: David Abrahams <dave(a)boost-consulting.com> >Subject: [C++-sig] Re: Embedding python and sigint >To: c++-sig(a)python.org >Message-ID: <uvfddtmpv.fsf(a)boost-consulting.com> >Content-Type: text/plain; charset=us-ascii > >Brian Murphy <brian.p.murphy(a)gmail.com> writes: > >> Hi, >> I have embedded python sucessfully in my multithreaded application but >> I have one problem. It seems that when I initialize the interpreter, >> sigint(ctrl-c) gets swallowed. I am running Fedora Core 2 and Python >> 2.3 compiled to a shared library. Is there any way; apart from writing >> my own signal handler and binding it to sigint, to allow normal >> sigints ? > >Brian, > >Sounds like this is not a C++-specific question. You might get >better answers on comp.lang.python. > >-- >Dave Abrahams >Boost Consulting >http://www.boost-consulting.com > > > >------------------------------ > >_______________________________________________ >C++-sig mailing list >C++-sig(a)python.org >http://mail.python.org/mailman/listinfo/c++-sig > > >End of C++-sig Digest, Vol 15, Issue 9 >************************************** > >.

1 0

Embedding python and sigint
by Brian Murphy Oct. 14, 2004

Oct. 14, 2004

Hi, I have embedded python sucessfully in my multithreaded application but I have one problem. It seems that when I initialize the interpreter, sigint(ctrl-c) gets swallowed. I am running Fedora Core 2 and Python 2.3 compiled to a shared library. Is there any way; apart from writing my own signal handler and binding it to sigint, to allow normal sigints ? Thanks, Brian

2 1

How can I use boost::python and Python API at the same time
by 千里马肝 Oct. 14, 2004

Oct. 14, 2004

Hi, How can I use boost::python and Python API at the same time? So, Which lib is the right lib I must link? It's boost_python_debug.lib or boost_python_pydebug.lib? Thanks for reply~

2 1