[Numpy-discussion] numpy and C99

Charles R Harris charlesr.harris@gmail....
Fri Oct 23 10:47:58 CDT 2009

On Fri, Oct 23, 2009 at 8:41 AM, Sturla Molden <sturla@molden.no> wrote:

> Dag Sverre Seljebotn skrev:
> > Microsoft's compilers don't support C99 (or, at least, versions that
> > still has to be used doesn't).
> >
> >
> Except for automatic arrays, they do support some of the more important
> parts of C99 as extensions to C89:
> inline functions
> restrict qualifier
> for (int i=0; i<; i++)
> Personally I think all of NumPy's C base should be moved to Cython. With
> your excellent syntax for PEP 3118 buffers, I see no reason to keep
> NumPy in C. This would make porting to Py3k as well as maintainence
> easier. When Cython can build Sage, it can be used for a smaller project
> like NumPy as well.
Sage doesn't have the accumulated layers of crud that numpy has. Yet ;)
However, moving parts of the code to cython is certainly one path forward. A
good starting point would probably be to separate ufuncs from ndarrays.
However, I think some code, say loops.c.src, looks better in C than it would
in cython. C is a rather nice language for that sort of thing. OTOH, the
ufunc_object.c code might look better in cython. In general, I think a
separation between pure C code and python interface code would be the way to
go, with the latter written in cython.

> The question of using C89, C99 or C++ would be deferred to the Cython
> compiler. We could use C++ on one platform (MSVC) and C99 on another
> (GCC). We would also get direct support for C99 _Complex and C++
> std::complex<> types.
How about symbol export control for the modules? I think that is one more
tool that would benefit from a portable interface in cython.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20091023/05fe2406/attachment.html 

More information about the NumPy-Discussion mailing list