Mailman 3 September 2006 - Cplusplus-sig

Difference between old and new Boost.Python interface.
by Roman Yakovenko Sept. 28, 2006

Sept. 28, 2006

Good evening. I think I found a bug. I expose a class that defines operator+. If I use old Boost.Python interface for wrapper construction all works as expected. If I use new interface, then I can not invoke it. Please consider next code: namespace bp = boost::python; struct vector_new{ vector_new(){} vector_new operator+( const vector_new& x ) const; static const vector_new v_new; }; struct vector_old{ vector_old(){} vector_old operator+( const vector_old& x ) const; static const vector_old v_old; }; struct vector_new_wrapper : vector_new, bp::wrapper< vector_new > { vector_new_wrapper() : vector_new(), bp::wrapper< vector_new >() {} vector_new_wrapper(vector_new const & arg ) : vector_new(), bp::wrapper< vector_new >() {} }; struct vector_old_wrapper : vector_old, bp::wrapper< vector_old > { vector_old_wrapper(PyObject* ) : vector_old(), bp::wrapper< vector_old >() {} vector_old_wrapper(PyObject*, vector_old const & arg ) : vector_old(), bp::wrapper< vector_old >() {} }; BOOST_PYTHON_MODULE( operators_ext ){ bp::class_< vector_new_wrapper >( "vector_new" ) .def( bp::self + bp::self ) .def_readonly( "v_new", vector_new::v_new); bp::class_< vector_old, vector_old_wrapper >( "vector_old" ) .def( bp::self + bp::self ) .def_readonly( "v_old", vector_old::v_old ); } I can invoke operator+ for vector_old class, but I can not invoke operator+ for vector_new class: import operators_ext old = operators_ext.vector_old() tmp = old + operators_ext.vector_old.v_old #this will work new = operators_ext.vector_new() tmp = new + operators_ext.vector_new.v_new #Previous line will raise TypeError: #TypeError: unsupported operand type(s) for +: 'vector_new' and 'vector_new' I attached minimal test case that reproduce the problem to the mail. Thank you. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/

3 9

please send me basic
by thilina sepala dahanayake Sept. 28, 2006

Sept. 28, 2006

I'm a new to c++, so I can't understand the hard things of c++.I want only basic of c++ I'll give you what I want - about Loops - what is arrys - what can i do from classes and objects - basic of oop I'll thank you very much if you send me above topics lectures thank you

2 1

Boost.Python, MinGW, & ImportError
by Corey Wright Sept. 28, 2006

Sept. 28, 2006

this is in reference to the following postings to c++-sig and boost-users: 1. http://lists.boost.org/boost-users/2006/02/17367.php 2. http://mail.python.org/pipermail/c++-sig/2006-September/011202.html the summary: individuals, including myself, are seeing "ImportError: dynamic module does not define init function (inithello)" whenever trying to import a module compiled with mingw against boost.python, specifically the python examples and tutorial distributed with boost. the symptom: g++ fails to properly link whenever a null library search path (ie -L"") is specified (because maybe it stops parsing arguments there?). the cause: MINGW_BIN_DIRECTORY is null the short answer (for those newbies just trying to get through the tutorial/example and don't care to dive into the details of boost.build): bjam -sMINGW_BIN_DIRECTORY=C:\MinGW\bin (or where ever your mingw installation is) the longer answer: see attached patch the explanation: A. in gcc-tools.jam: 1. the gcc-Link-action contains -L"$(STDLIBPATH:T)" 2. STDLIBPATH is set based on following commands: a. flags gcc GCC_STDLIB_DIRECTORY : $(GCC_STDLIB_DIRECTORY) ; b. GCC_STDLIB_DIRECTORY ?= $(GCC_ROOT_DIRECTORY)$(SLASH)lib ; c. flags gcc STDLIBPATH : $(GCC_STDLIB_DIRECTORY) ; but when using mingw, the values in gcc-tools.jam are set... B. in mingw-tools.jam 1. local GCC_BIN_DIRECTORY = $(MINGW_BIN_DIRECTORY) ; 2. local GCC_STDLIB_DIRECTORY = $(MINGW_STDLIB_DIRECTORY) ; 3. flags mingw STDLIBPATH : $(GCC_BIN_DIRECTORY) ; so for mingw, STDLIBPATH is always composed of GCC_BIN_DIRECTORY (which is really MINGW_BIN_DIRECTORY). if you set MINGW_STDLIB_DIRECTORY, but not MINGW_BIN_DIRECTORY, you end up with -L"mingw_stdlib_directory" -L"". you must set MINGW_BIN_DIRECTORY to get rid of the null string or insure the null string in MINGW_BIN_DIRECTORY never gets added to STDLIBPATH. i successfully compiled boost.python without needing to set MINGW_BIN_DIRECTORY because the mingw tools are in my path and everything "just works". but if you try to compile python extensions (or at least the tutorial and examples), then things start mysteriously failing. i haven't had time to fully test my patch by building all of boost with it applied, but i'm currently in the process and last i looked bjam had compiled date and filesystem libraries, and was working on iostreams. thanks for boost.python and the mingw support (it feels liberating to compile free software, gratis & libre, with free software; and we'll overlook the operating system ;-). -- undefined(a)pobox.com

2 3

Re: [C++-sig] (Philip Austin) numpy.ndarray did not match PyArrayObject
by Qinfeng(Javen) Shi Sept. 27, 2006

Sept. 27, 2006

Hi Philip, It is GREAT!. You code works! It is quite different from the numpybook 2006 or some online resources which I can find. Could please you provide some good stuffs about it here so that I can study it? Thanks you so much! Cheers! -- Qinfeng(Javen) Shi Research School of Information Sciences and Engineering Australian National University Locked Bag 8001 Canberra ACT 2601

2 1

Py++ and caching
by Kirill Lapshin Sept. 27, 2006

Sept. 27, 2006

Hi Roman, Is there a way to not regenerate source code if cache is valid? I.e. currently cache saves us from running gccxml, but the whole code generation phase is still carried out even though it does not really changes anything (unless there was a change in driver .py script). Ideally I think what has to be done is: add an option to Py++ that will say these files are also a dependency (in addition to header(s) we are parsing with gccxml and the whole tree of headers #included from there); Py++ will run gccxml as before, only when needed, and will run code generation only if gccxml has been run or any additional dependencies have been modified since last time. We'll list driver script as additional dependency. This will reduce runtime of Py++ to almost zero if no changes are needed. I think I should be able to do something similar externally by tracking additional dependencies myself and asking cache prior to instantiating module builder. However I would imagine others may benefit from such functionality as well. Unless it already exists that is. :) Best regards, Kirill

2 3

[boost][python2.5] "with" support
by Colin Grealy Sept. 27, 2006

Sept. 27, 2006

Now that python 2.5 has been released, are there any plans for adding support to bpl for the new language features? Specifically will there be support for the __enter__() and __exit__() special "with" methods? I think that most C++ developers would embrace this feature as it's close to the RAII idiom that modern C++ uses. Colin

4 3

Re: [C++-sig] (David Abrahams)numpy.ndarray did not match PyArrayObject *
by Qinfeng(Javen) Shi Sept. 27, 2006

Sept. 27, 2006

Hi David, >boost::python::lvalue_from_pytype<extract_array_object,&PyArrayObject_Type>(); >struct extract_array_object > { > static PyArrayObject& execute(PyArrayObject& x) > { > return x; > } > }; > Yes, the very subtle trick at the bottom of my posting > "replace the indicated with the name of NumPy's python type object > for ndarray." Sorry, I don't get you. The Python type of the ndarray is PyArray_Type. InC, every ndarray is a pointer to a PyArrayObject structure. So what is the extract_array_object and what is PyArrayObject_Type? I tried boost::python::lvalue_from_pytype<PyArray_Type,&PyArrayObject>(); boost::python::lvalue_from_pytype<extract_array_object,&PyArray_Type>(); boost::python::lvalue_from_pytype<ndarray,&PyArray_Type>(); boost::python::lvalue_from_pytype<extract_array_object,&PyArrayObject_Type>(); boost::python::lvalue_from_pytype<extract_array_object,&ndarray>(); boost::python::lvalue_from_pytype<PyArray_Type,&PyArray_Type>(); boost::python::lvalue_from_pytype<ndarray,&ndarray>(); boost::python::lvalue_from_pytype<PyArray_Type,&ndarray>(); They all failed. Could you please tell me exactly? -- Qinfeng(Javen) Shi Research School of Information Sciences and Engineering Australian National University Locked Bag 8001 Canberra ACT 2601

3 3

PyArg_ParseTuple() failed in parsing args
by Qinfeng(Javen) Shi Sept. 27, 2006

Sept. 27, 2006

Dear all, According the knowledge from http://numpy.scipy.org/numpydoc/numpy-13.html It seems when input args is numpy.ndarray, it uses PyArg_ParseTuple(args, "O!", &PyArray_Type, &array)) to convert PyObject* args into PyArrayObject* array. Then we can handle the array in c extension. But this PyArg_ParseTuple( ) failed(not crashed) when I used it in python environment(even when I put a real tuple into args). I have #define PY_ARRAY_UNIQUE_SYMBOL Javen and import_array(); and even #include "ufuncobject.h"; Is that possible to make it work? I guess I missed some subtle thing. Thanks! -- Qinfeng(Javen) Shi Research School of Information Sciences and Engineering Australian National University Locked Bag 8001 Canberra ACT 2601

1 0

(no subject)
by Philip Austin Sept. 27, 2006

Sept. 27, 2006

Qinfeng(Javen) Shi writes: > Hi Philip and David > > What I really want to do is to access numpy.ndarray in c extension. I tried > 2 ways and Philip told me another possible way but I failed. The two appended files work for me with FC3 Linux -- Phil #define PY_ARRAY_UNIQUE_SYMBOL PyArrayHandle #include <boost/python.hpp> #include <numpy/noprefix.h> #include <iostream> namespace bp=boost::python; namespace ar=boost::python::numeric; //get a numeric array and double it void testFromPython(ar::array inValue){ double* dataPtr = (double*) PyArray_DATA(inValue.ptr()); std::cout << std::endl << "data values on c++ side: " << std::endl; intp theSize=PyArray_Size(inValue.ptr()); for(int i=0;i < theSize;++i){ std::cout << *(dataPtr + i) << std::endl; } } BOOST_PYTHON_MODULE(numtest_ext) { import_array(); ar::array::set_module_and_type("numpy", "ndarray"); std::string str1 = "Doc string for testFromPython\n"; def("testFromPython", testFromPython,str1.c_str()); } """when I run this script I get: ~/philprojects/pythonlibs/num_util phil@gull% python test.py data values on c++ side: 0 1 2 3 4 5 6 7 8 9 """ import numpy as n import numtest_ext as ne theArray=n.arange(10,dtype='Float64') ne.testFromPython(theArray)

1 0

Re: [C++-sig] (Philip Austin) (David Abrahams)numpy.ndarray did not match PyArrayObject
by Qinfeng(Javen) Shi Sept. 27, 2006

Sept. 27, 2006

Hi Philip and David What I really want to do is to access numpy.ndarray in c extension. I tried 2 ways and Philip told me another possible way but I failed. ----------------------------------------------------- hello.c 1st way: void testArray(PyArrayObject * args) { } >>> hello.testArray(b) Traceback (most recent call last): File "<stdin>", line 1, in ? Boost.Python.ArgumentError: Python argument types in hello.testArray(numpy.ndarray) did not match C++ signature: testArray(PyArrayObject*) >>> ------------------------------------------------------hello.c 2nd way: void testArray(PyObject * args) { PyObject *input; PyArrayObject *array; if (!PyArg_ParseTuple(args, "O", &input)) printf("getting input failed!\n"); else printf("getting input sucess!\n"); } >>> import hello >>> import numpy >>> c = numpy.arange(25).reshape((5,5)) >>> d = hello.testArray(c); getting input failed! >>> d SystemError: new style getargs format but argument is not a tuple >>> then I tried adding following lines asPhilip told me to hello.cpp file. ------------------------------------------------hello.cpp namespace ar=boost::python::numeric; namespace bp=boost::python; import_array(); ar::array::set_module_and_type ("numpy", "ndarray"); It didn't crash but still had error. The interesting thing is that now running it twice would get two different error informations. ---------------------------------------------------error report in python >>> import hello >>> import numpy >>> a = numpy.arange(25).reshape((5,5)); >>> hello.testArray(a) // first time SystemError: new style getargs format but argument is not a tuple >>> hello.testArray(a) // second time args is array type! //it means PyArray_Check(args) successed this time. getting input failed! //PyArg_ParseTuple() failed but not crashed I am upset why I can't access numpy.ndarray. Any suggestion? Thanks! -- Qinfeng(Javen) Shi Research School of Information Sciences and Engineering Australian National University Locked Bag 8001 Canberra ACT 2601

1 0