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

[Fernando Perez]

Andrew Straw wrote:

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

Well, I'm pretty sure that when I first downloaded that code (about a month
ago) it was not using cimport and pxd files, which is why I made those
changes.  I started using that code from a download at rev.6, which did use 
the 'old style', and didn't look at the wiki since:

http://scipy.org/Cookbook/Pyrex_and_NumPy?action=diff&rev2=14&rev1=6

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

Again, I was using the old code before your updates.  I'm pretty sure that I 
did look at the wiki in February though, it's possible that my browser's cache 
played a trick on me, because your updates were done in February while the 
'old' code seems to be from January.

Anyway, it doesn't matter: what I did is very close to what you have now, I 
only have a more complete c_numpy file (stolen from mtrand) and a full pair of 
Makefile/setup.py, which can be handy for 'out of the box' usage.

> 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").

I certainly hope we are NOT going to make setuptools a dependency or a 
requirement for numpy/scipy.  I've had no end of problems with it (which R. 
Kern has patiently dealt with in private) and I am allergic to the thing. 
I've seen it break plain 'setup.py install' installations with the most 
bizarre of errors, and I have a feeling that it's a tool whose marketing 
quality far outpaces its technical merits, at least in some contexts.  Robert 
has calmly explained to me how it DOES have very useful features for certain 
problems, so I respect its use where needed (I've even made sure that ipython 
plays nicely with it, inasmuch as I can).

But given how making a plain distutils-based setup.py file which knows about 
pyrex files (it won't call pyrexc if the .c file is present, I think) isn't 
that hard, I'd prefer NOT to have setuptools be a dependency.  The less things 
numpy depends on, I think the better off we all are.


Cheers,

f