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

[Andrew Straw]

Fernando Perez wrote:

> Andrew Straw wrote:
>
>> 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.
>
> 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.

OK, I just hope you update your code to use Python's Py_intptr_t. I
think it will be more robust.

>> 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'm not proposing we do so. The 'setuptools aware' proposal above allows
making use of a setuptools feature without requiring it. I agree this
could be done in a few lines of code without setuptools, I was just
making a suggestion for improvement to your setup.py file to make it
more robust to the presence or absence of Pyrex.

I like the present situation where numpy is very compatible with
setuptools and I appreciate that ipython is also. I don't see what
benefits numpy and scipy would get from _requiring_ setuptools, either,
so we agree that there is no reason to do so.

I'm sorry you've had such a bad time with setuptools but it solves many
problems for me. The main developer of setuptools, Philip Eby, is very
receptive to suggestions, comments, and criticisms, and given the
significant chances of setuptools being incorporated into Python sooner
rather than later, I'd suggest airing any remaining complaints soon or
be forced to deal with them for a long time to come.