From dholth at fastmail.fm Sun Feb 1 01:43:10 2004 From: dholth at fastmail.fm (Daniel Holth) Date: Sat, 31 Jan 2004 19:43:10 -0500 Subject: [C++-sig] Boost.Python functions and Python functions Message-ID: <1075596189.31783.69.camel@bluefish> Boost.Python functions don't inherit from the Python function type, but if they did the current version of pydoc would show their docstring. So, if we want help(boost_module_with_functions) to show something, we can change pydoc so it knows about Boost.Python functions, or change Boost.Python functions to inherit from the Python function type. Is there a good reason that Boost doesn't currently subtype Python's Function Type for its functions? - dwh From dave at boost-consulting.com Sun Feb 1 03:22:10 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 31 Jan 2004 21:22:10 -0500 Subject: [C++-sig] Re: iterator interface question (progress!) References:

Message-ID: Neal Becker writes: >> Better make begin and end functions use return_internal_reference, so >> the iterators won't outlive the container. UNfortunately, they're >> still not safe since they can still run off the end of the vector or >> become invalidated. These are the sorts of issues that the indexing >> suites should handle. >> > > Thanks for the help, but I still have 1 question about your reply (the > meaning of "should"). Do you mean the indexing suites already do provide a > better solution (and I should look at it) or do you mean that you wish the > indexing suites provided a better solution, and may in the future? I mean that they already do provide better solutions. That said, they don't expose a C++ iterator idiom; they expose a Python iterator idiom. It's generally accepted that C++ code wrapped in Python should behave Pythonically. Python users probably won't understand your crazy begin()/end() interface ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sun Feb 1 03:29:23 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 31 Jan 2004 21:29:23 -0500 Subject: [C++-sig] Re: Boost.Python functions and Python functions References: <1075596189.31783.69.camel@bluefish> Message-ID: Daniel Holth writes: > Boost.Python functions don't inherit from the Python function type, but > if they did the current version of pydoc would show their docstring. > > So, if we want help(boost_module_with_functions) to show something, we > can change pydoc so it knows about Boost.Python functions, or change > Boost.Python functions to inherit from the Python function type. If pydoc really only works on classes derived from Python's builtin function types, it probably *should* be changed. > Is there a good reason that Boost doesn't currently subtype Python's > Function Type for its functions? You mean aside from: >>> def f():pass ... >>> f.__class__ >>> class x(f.__class__): ... pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: type 'function' is not an acceptable base type ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dholth at fastmail.fm Sun Feb 1 10:45:08 2004 From: dholth at fastmail.fm (Daniel Holth) Date: Sun, 01 Feb 2004 04:45:08 -0500 Subject: [C++-sig] Re: Boost.Python functions and Python functions In-Reply-To: References: <1075596189.31783.69.camel@bluefish> Message-ID: <1075628708.4490.33.camel@bluefish> On Sat, 2004-01-31 at 21:29, David Abrahams wrote: > If pydoc really only works on classes derived from Python's builtin > function types, it probably *should* be changed. > > > Is there a good reason that Boost doesn't currently subtype Python's > > Function Type for its functions? > > You mean aside from: ... > TypeError: type 'function' is not an acceptable base type > > ?? This is the exact test pydoc (via inspect.py) uses to determine if something is a function: "isinstance(object, types.FunctionType)". This evaluates to true for PyCFunction and PyFunction, builtin functions and normal Python functions, so perhaps Boost's functions can be made to to pass this test. pydoc could also be changed to document as a function anything that had a __call__ property. - dwh From dave at boost-consulting.com Mon Feb 2 23:23:40 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Feb 2004 17:23:40 -0500 Subject: [C++-sig] Re: Manipulating arguments with CallPolicies::precall? References: Message-ID: Arve Knudsen writes: > Hi > > I want to wrap a native C Python object in a C++ object that takes > care of constructing and destructing it properly I don't understand. Do you mean something akin to boost::python::list, or something entirely different? > (there isn't any way > to specify custom allocation/deallocation routines are > there?) I don't understand the question. allocation/deallocation routines for what? > However, I would like to send this object directly to the > associated routines (its part of an existing Python extension). What associated routines. > I haven't found any direct support for this kind of thing within > boost::python, since everything seems strongly tied to the contained > type (my wrapping C++ class). But, I figured it might be possible to > manipulate the Python argument tuple within CallPolicies::precall? Sorry, I'm completely lost. I suggest you show some code that demonstrates what you'd like to be able to do, but which isn't supported. I didn't try very hard to understand the rest of the message, because I didn't even get this far :( -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Feb 2 23:24:57 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Feb 2004 17:24:57 -0500 Subject: [C++-sig] Re: Problem with pickling returning a boost::python::dict object References: <1074868452.24889.35.camel@pbarbier> <20040123175330.51923.qmail@web20204.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > (something like dict save; make_tuple(object_dict, save)). or make_tuple(object_dict, dict()) ? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Feb 2 23:34:47 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Feb 2004 17:34:47 -0500 Subject: [C++-sig] Re: implicitly_convertible References: <200401201633.i0KGXK3N2721117@vracs001.vrac.iastate.edu> Message-ID: "aashish" writes: > Hi, > > I wanted to have a function like this where when I pass a list I will either > get return as set of integers or std::vector of double. > > I tried to implement the function in this manner ..... > > C++-------------------------------- > int make_vector(bp::list vlist) > { > //std::vector vector_list; > int k = extract(vlist.attr("__len__")()); > > /*for (int i=0;i<10;i++) > { > > vector_list.push_back(extract(lt.attr("__getitem__")(i))); That's the hard/ugly way. Why not: vector_list.push_back(extract(lt[i])); ?? > } > > return vector_list;*/ > > int kk = extract(vlist.attr("__getitem__")(0)); > > return kk; > } > Python----------------------------- > > L = ['1','2','3'] > a = make_vector(L) > print a > > The problem is that I am getting the correct value for 'k' here but then it > does throws error saying that > > Tracekack(most recent call last) > File "pytest2.py" , line 30, in ? > A = "make.vector"(L) ^^^^^^^^^^^^^ I can't believe that you copied this error message correctly. > Typeerror: No registered converter was able to produce a C++ rvalue of type > int from this Python object of type str. > > Now what does this error mean?? The error means that you tried to extract from a Python string object. > And How can sole this problem. Store ints instead of strings in L L = [ 1, 2, 3 ] ?? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Feb 2 23:37:18 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Feb 2004 17:37:18 -0500 Subject: [C++-sig] Re: implicitly_convertible References: <200401201531.i0KFVg3N2714865@vracs001.vrac.iastate.edu> Message-ID: "aashish" writes: > Hi, > > This might be a very simple question but I am wondering when I should use > > implicitly_convertible as I found that in certain cases the coversion from > Python type to C++ type is possible without using it. implicitly_convertible isn't there just to enable Python->C++ conversions. Many built-in conversions work automatically. if there exists a conversion from Python type P -> C++ type C implicitly_convertible(); will enable a conversion from Python type P -> C++ type D -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Feb 2 23:44:08 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Feb 2004 17:44:08 -0500 Subject: [C++-sig] Re: Operator== for reflected enums can return True when it shouldn't? References: Message-ID: "Pete Bartlett" writes: > (Apologies if this issue has been raised before - I must have put the > wrong search terms into Google) > > On my setup (Python 2.3, boost-cvs from early December, MSVC 7.1), > Python returns True when comparing two reflected enums of different type > that have the same internal integer representation. Though I am sure it > is bad Python style to compare different types, would it right and > possible to return False in this case? It depends how you view enums. Many people use them for simple constants, and in that case they should behave as C++ enums do, so they are comparable with other same-valued enums. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Feb 2 23:42:10 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 02 Feb 2004 17:42:10 -0500 Subject: [C++-sig] Re: New slice implementation References: <1073361918.13426.31.camel@illuvatar> <1073518393.1796.15.camel@illuvatar> <1073595081.19758.430.camel@illuvatar> <1073620180.19759.565.camel@illuvatar> <1073665816.19758.775.camel@illuvatar> <65fk1opl.fsf@boost-consulting.com> <1073970573.27246.67.camel@illuvatar> <1074047914.1215.43.camel@illuvatar>

<1074473408.8246.3.camel@illuvatar> <1075252218.12314.14.camel@illuvatar> Message-ID: Jonathan Brandmeyer writes: >> sourceforge user id (the textual one) and I'll give you Boost CVS >> access so you can check this in yourself. > > My Sourceforge ID is "jbrandmeyer". Added. > There is also (hopefully only) one > remaining detail. How exactly is the testsuite driven? Or, phrased > differently, what do I need to do to get the tests to run automatically > when you execute `bjam test`? If it isn't obvious after looking at libs/python/test/Jamfile, let me know and I'll give you more detail. -- Dave Abrahams Boost Consulting www.boost-consulting.com From aashish at vrac.iastate.edu Tue Feb 3 16:49:38 2004 From: aashish at vrac.iastate.edu (aashish) Date: Tue, 3 Feb 2004 09:49:38 -0600 Subject: [C++-sig] Re: CVS version on VC++ 7.0 In-Reply-To: Message-ID: <200402031550.i13Fop3N9677172@vracs001.vrac.iastate.edu> Hi, I need to use the new conversion -> register_ptr_to_python.hpp in my project and register_ptr_to_python.hpp is only available in the CVS version of the boost. So what I did is I got the cvs version and was trying to add the project file into my project using Microsoft VC++ 7.0. For that I was trying to include the boost/libs/python/build/VisualStudio/"project file". It was asking me whether it should be converted for VC7.0. When you do that it says the file is corrupted "unable to load the project". Please let me know how to get the project file of boost.python on VC++ 7.0. ~regards, Aashish From aknuds-1 at broadpark.no Tue Feb 3 20:12:08 2004 From: aknuds-1 at broadpark.no (Arve Knudsen) Date: Tue, 03 Feb 2004 20:12:08 +0100 Subject: [C++-sig] Re: Manipulating arguments with CallPolicies::precall? In-Reply-To: References:

Message-ID: It looks like raw_function is definitely the way to go here. It's not as painless as I was hoping for, but such is life. ;) Thanks a heap! ~Shaun David Abrahams wrote: > GameGuy writes: > > >>Hello. >>I have been using PYSTE and Boost.Python to wrap a C++ library for use in Python. Very nice stuff. >> >>I have reached a stumbling block though: There are several methods in >>this library that have an ellipsis in their method declarations. Eg: >> >>class Foo >>{ >> virtual void method(const char* bar, ... ) const = 0; >>}; >> >>Which I think can be wrapped with Boost.Python in the following way: >> >>struct Foo_Wrapper : Foo >>{ >> // ... >> >> virtual void method(const char* p0, ... ) const { >> va_list args; >> va_start(args, p0); >> call_method< void >(self, "method", p0, args); >> } >>}; >> >>// ... >> >> class_< Foo, Foo_Wrapper >("Foo", init< >()) >> .def("method", &Foo::method) >> ; >> >> >>I saw it done this way in another library. I haven't verified that it >>works or not yet as I can't compile it yet (running into MSVC7 >>issues). >> >>Has anyone else had experience wrapping functions with variable argument lists? >>Will this work in Boost.Python? > > > > Short answer: no, this doesn't work. > > Longer answer: you can't really get this to work in Boost.Python > because it relies on being able to deduce the expected C++ types of > arguments. > > Longer answer still: you might be able use > BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS to wrap this method for > specific sequences of arguments. > > http://tinyurl.com/2wptk > > But now that I look I think it'll fail for the same reason. I think > the need to use call_method internally might give you problems, too. > > I think your best bet might be to use the facilities of > http://www.boost.org/libs/python/doc/v2/raw_function.html > > >>Is it worth extending PYSTE to handle these cases? (It doesn't currently) >> >> >>Thank you for any assistance, >>~Shaun > > From dave at boost-consulting.com Mon Feb 16 14:09:16 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 16 Feb 2004 08:09:16 -0500 Subject: [C++-sig] Re: Boost.Python proposed patch 1.31.0 In-Reply-To: <40306886.8040008@quakes.uq.edu.au> (John Gerschwitz's message of "Mon, 16 Feb 2004 16:51:50 +1000") References: <40298000.902@quakes.uq.edu.au> <402B225F.9070502@quakes.uq.edu.au> <40306886.8040008@quakes.uq.edu.au> Message-ID: John, Please ask Boost.Python questions on the C++-sig unless you want to hire Boost Consulting to help you. John Gerschwitz writes: > Hi Dave, I've had to continue with the patch to the numeric unit test > at home. The behaviour is not what I expected. Everything works fine > just as it is, ie the test comes back saying it has passed. Within > numpy.cpp making the calls to numeric::array nelements(), isaligned(), > iscontiguous(), itemsize() doesn't cause a failure prior to the > patch. This is not what I expected, I expected these calls to generate > an exception. Is there an easy way to run the tests through the > debugger? bjam numpy --debugger=whatever will put "whatever" at the beginning of the command line that runs the test. I use "--debugger=devenv /debugexe". > As you have probably guessed I'm trying to use the Boost.Python > library with numarray. I'm finding the documentation a little on the > light side. Yup. > Can you point me to more comprehensive documentation? All I know about is in the Boost.Python reference, but you might check the list (http://article.gmane.org/gmane.comp.python.c++/4070) or the wiki > I'm > particularly interested in copying data from a numarray into a C++ > data structure. I'm not sure what facilities Boost.Python provides to > make such a task easier. > > Thanks John > -- Dave Abrahams Boost Consulting www.boost-consulting.com From gameguy at eastlink.ca Mon Feb 16 14:51:29 2004 From: gameguy at eastlink.ca (GameGuy) Date: Mon, 16 Feb 2004 09:51:29 -0400 Subject: [C++-sig] Ellipsis parameter not handled in PYSTE Message-ID: FYI, Normally this really isn't a problem, but if the ellipsis is used in the definition of a pure virtual member function then we get compilation errors. PYSTE also tries to expose the member function in the class definition in the module. As discussed already, this can't be done automatically (thanks David!). I'm not exactly sure how PYSTE should wrap the pure virtual method so that it's portable (I'm kind of new to C++ so I may be professing ignorance here), but it definitely shouldn't be exposed in a .def in the class. ~Shaun Foo.cpp \Boost\include\boost-1_31\boost\python\object\value_holder.hpp(71) : error C2259: '`anonymous-namespace'::Foo_Wrapper' : cannot instantiate abstract class due to following members: 'void Foo::method(const char *,...) const' : pure virtual function was not defined Foo.h(3) : see declaration of 'Foo::method' \Boost\include\boost-1_31\boost\type_traits\alignment_of.hpp(37) : see reference to class template instantiation 'boost::python::objects::value_holder_back_reference' being compiled with [ Value=Foo, Held=boost::python::class_::held_type ] \Boost\include\boost-1_31\boost\type_traits\alignment_of.hpp(52) : see reference to class template instantiation 'boost::detail::alignment_of_hack' being compiled with [ T=holder ] \Boost\include\boost-1_31\boost\type_traits\alignment_of.hpp(61) : see reference to class template instantiation 'boost::detail::alignment_of_impl' being compiled with [ T=holder ] \Boost\include\boost-1_31\boost\python\object\instance.hpp(30) : see reference to class template instantiation 'boost::alignment_of' being compiled with [ T=holder ] \Boost\include\boost-1_31\boost\python\object\instance.hpp(45) : see reference to class template instantiation 'boost::python::objects::instance' being compiled with [ Data=holder ] \Boost\include\boost-1_31\boost\python\class.hpp(643) : see reference to class template instantiation 'boost::python::objects::additional_instance_size' being compiled with [ Data=holder ] \Boost\include\boost-1_31\boost\function\function_template.hpp(383) : while compiling class-template member function 'void boost::python::class_::register_holder(void)' with [ T=Foo, X1=boost::noncopyable, X2=`anonymous-namespace'::Foo_Wrapper ] Foo.cpp(37) : see reference to function template instantiation 'boost::python::class_::class_>(const char *,const boost::python::init_base &)' being compiled with [ T=Foo, X1=boost::noncopyable, X2=`anonymous-namespace'::Foo_Wrapper, DerivedT=boost::python::init<> ] -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Foo.h URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Foo.cpp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Foo.pyste URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Foo.xml Type: text/xml Size: 1591 bytes Desc: not available URL: From dave at boost-consulting.com Mon Feb 16 15:23:15 2004 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 16 Feb 2004 09:23:15 -0500 Subject: [C++-sig] Re: beginner : call_policies References: Message-ID: "Benjamin Golinvaux" writes: > Dear list members, > > I would like to know if it's possible to write my own > call policies, in order to be able to handle the reference > counting of objets dynamically, based on some return values > of my wrapped C++ functions. For example > > struct A {}; > > struct B > { > bool foo(A& someA); > A _a; > } > > where i would like B::foo(someA) to increment someA reference count > if it returns "true", and don't do anything otherwise. > (so basically i would like to tie someA's lifetime to the instance > of B ONLY IF the function returns "true". > > is this possible with some precall/postcall magic ? Yes, it certainly is possible. -- Dave Abrahams Boost Consulting www.boost-consulting.com From gameguy at eastlink.ca Mon Feb 16 16:18:00 2004 From: gameguy at eastlink.ca (GameGuy) Date: Mon, 16 Feb 2004 11:18:00 -0400 Subject: [C++-sig] Re: Problem with current pyste and inheritance In-Reply-To: <4016F0A9.8050105@esss.com.br> References: <25582984.1075234165@localhost> <4016F0A9.8050105@esss.com.br> Message-ID: I'm not sure if this is related, but I found another inheritance problem: Attached are the files necessary to reproduce: 2 classes: A and B. B is derived from A. A defines a method, getA, to illustrate the point more clearly. The method is not necessary to reproduce the problem. If I only put B.pyste in the pyste command line specifying "--multiple", PYSTE won't output the proper bases