[C++-sig] Status of Numpy support in boost python

Stefan Seefeld seefeld at sympatico.ca
Mon Mar 8 20:38:11 CET 2010

On 03/08/2010 02:11 PM, Jim Bosch wrote:
>> I think it would be useful to integrate the PyArray wrapper right into
>> boost.python.
> I generally agree, but I dislike the idea of including the numpy C-API
> header file in all its preprocessor-macro glory in a file which will be
> included by users, and I've found it hard to avoid that in a header-only
> library.  What was your solution?

In my setup I check for the python-numpy package (on Fedora), which 
provides the numpy/arrayobject.h header (assuming this is the one you mean).

However, I'm not sure I understand your concern. Boost.python isn't a 
header-only library, so it may well hide the above header by compiling 
it into its own object file.

To me, the most important feature in adding proper PyArray support to 
boost.python is the ability to access the much richer API, such as 
direct-data access via PyArr_DATA, PyArr_GETPTRX, etc., which allow me 
to build my own adapter, so different parts of a hybrid application can 
pass arrays around without the need to copy.

>> Other libraries which provide more functionality (such as pyublas, or
>> the one Jim is talking about) can then use that wrapper, instead of
>> having to provide it themselves. This should notably also improve
>> interoperability, since the boost.python type registry doesn't (yet)
>> allow multiple wrappers for the same types.
> This does seem like the best way to go, if we can find a solution to the
> numpy header problem that doesn't require building the boost.python
> library itself against numpy.

Hmm, this is a good point: By compiling the numpy wrapper as part of 
boost.python, we would make numpy a prerequisite for boost.python, which 
isn't a good idea. So keeping it header-only may be better.
I'm still not sure what your concern is with the numpy header. Why can't 
it be exposed to user code ?

May be you can indeed make a case for a compiled boost.numpy library...

> By the way, here's what I've got - it seems to complement pyublas pretty
> well:
> - A few "object manager" types for numpy.ndarray, numpy.dtype,
> numpy.matrix, and numpy.void scalars, and a pretty easy system for
> adding more.  These present a boost.python interface to the parts of the
> Numpy C-API, and it sounds like they're pretty similar in spirit to your
> PyArray.  I'll look into putting them into the sandbox.

That looks good. Thanks !

> - A tool for creating broadcasting python callables from arbitrary C++
> objects that overload operator().

Would this be a generator for ufuncs ?

> - A multidimensional array template library patterned after numpy; this
> is definitely not something that belongs in boost.python, but I find
> that they work very well together:
> http://code.google.com/p/ndarray/

Ah. That sounds useful, but I agree, not like something that belongs 
into a generic numpy wrapper library.

> It would really great if boost.multiarray could fill such a role, but I
> found it doesn't do everything needed in talking to numpy - particularly
> the ability to handle shared data.

Thanks. I'd very much like to see a discussion of how to move the above 
numpy wrapper into boost.python (possibly as a new compiled boost.numpy 



       ...ich hab' noch einen Koffer in Berlin...

More information about the Cplusplus-sig mailing list