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

[Jim Bosch]

On Mon, 2010-03-08 at 14:38 -0500, Stefan Seefeld wrote: 
> 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.
> 

I agree.  The whole point of using numpy with C++ is to be able to go
from raw pointers to numpy arrays and back, and that doesn't seem to be
possible with an interface that just calls the Python API (as the
numeric interface does at present).

> 
> 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 ?
> 

I just don't like that you have to #define something before including
the header, and that it's different in the source file that calls
"import_array()" than in all the others.  In fact, I find it unfortunate
that "import_array()" needs to be called at all, but I haven't found a
way around that.  I'm also mildly annoyed that it doesn't #include
<Python.h> even though it requires it.

This is all just a really ugly replacement for namespaces, and it may be
necessary in C extensions, but shouldn't be necessary in a C++
extension.  You should be able to just do
"#include <boost/python/numpy.hpp" 
(or whatever) and have it all just work.

Maybe I'm placing too much value in hiding that from the user, though.

> 
> > - A tool for creating broadcasting python callables from arbitrary C++
> > objects that overload operator().
> >    
> 
> Would this be a generator for ufuncs ?
> 

Not in any technical sense of the word "generator", I think, and it
doesn't actually use the numpy.ufunc type (because that requires a true
function pointer), but that's essentially the idea.

Finally, I've checked in what I have so far in the sandbox:

http://svn.boost.org/svn/boost/sandbox/numpy/

There's still a lot to do before I'd call it complete, but it has (IMO)
the most important low-level functionality.  If anyone wants to toss in
a bjam-based build system, I'd much appreciate it - I don't know jam at
all.


Jim