[Numpy-discussion] Access to C/C++, typemaps, pyrex...

Andrew Straw strawman at astraw.com
Sun Mar 12 16:51:06 CST 2006


Fernando Perez wrote:

> At the last scipy conference, I collected typemaps from a number of
> people who had them around and all I could find on the net.  [snip] 
> I'm finally doing something about it, so today I updated this code to
> work with numpy instead of Numeric, and all the tests pass.

Thanks Fernando, I think this is great.

> I think it would be a good starting point to have distributed
> /officially/ with numpy.  That way others can improve /this/ code,
> rather than reimplementing numpy typemaps for the millionth time.

+1

> 2. Pyrex
> ========
>
> After reading the excellent cookbook examples on pyrex usage, which I
> recently needed for a project, I decided to complete the code so it
> could be used 'out of the box'.  This simply meant a bit of
> organization work, updating the code to use the 'modern' cimport
> statement and .pxd files, and writing a proper setup.py file.

What do you mean 'modern' cimport and .pxd statement?  I believe the
example at http://scipy.org/Cookbook/Pyrex_and_NumPy is fundamentally no
different than yours. One question, though: why have you reverted from
using Python's Py_intptr_t and used intp instead? It seems to me much
more likely that Py_intptr_t will be available and will do the Right
Thing than relying on some libc to define it. We've seen broken
implementations of C libraries before, and I say let's trust the Python
devs to get this one right.

>   The result is here:
>
> http://wavelets.scipy.org/svn/multiresolution/wavelets/trunk/numpyx/
>
> I also think that pyrex should be 'officially' supported.  In
> particular, I think that the c_numpy.pxd file I put there, which is
> just a copy of that in mtrand, should be completed and shipped in the
> same headers directory as the rest of numpy's .h files.  This would
> make it a LOT easier for newcomers to use pyrex for writing numpy
> extensions, since all headers would be complete and available with all
> numpy installations.

+1

> Getting this right took some time, as not all the details for this
> kind of construction are clearly documented anywhere.  I hope it may
> be useful to others.

Note that setuptools 'automatically' deals with .pyx files: If you pass
a source file that ends in .pyx, setuptools will run pyrexc on it if
Pyrex is available, and otherwise use a '.c' file by the same name in
the same directory. This is nice because it means you can ship .c files
with your project and people can build them, even if they don't have
Pyrex installed. Maybe we want to ship two setup.py files, or one that
is "setuptools aware" (checks for setuptools with "if 'setuptools' in
sys.modules").

Finally, a more general question: now that ctypes will become an
official part of Python with 2.5, should we visit the idea of an
'official' numpy/ctypes binding? I used ctypes once about 3 years ago,
so I'm not qualified to have an opinion on this, but while this stuff is
in the wind...




More information about the Numpy-discussion mailing list