[Numpy-discussion] Ctypes support in NumPy

[Albert Strasheim]

Hello all,

Travis Oliphant wrote:
> Hey Albert,  I read the post you linked to on the ctypes mailing list.
> I hope I didn't step on any toes with what I did in NumPy.   I was just

Certainly not. This is great stuff!

> working on a ctypes interface and realized that a lot of the cruft to
> convert to what ctypes was expecting could and should be handled in a
> default way.  The conversion of the shapes and strides information to
> the "right-kind" of ctypes integer plus the inclusion of ctypes in
> Python 2.5 was enough to convince me to put some kind of hook into the
> array object.  I decided to make the ctypes attribute return an object
> so that the object could grow in the future additional attributes and/or
> methods to make it easier to interface with ctypes.

Ah! So arr.ctypes.* is a collection of things that one typically needs to
pass to C functions to get them to do their work, i.e. a pointer to data and
some description of the data buffer (shape, strides, etc.). Very nice.

> <snip>

> Basically, what you need is a type-map just like swig uses.  But, now
> that ctypes is in Python, it will be slower to change.  That's a bit
> unfortunate.

If we find the ctypes in Python 2.5 to be missing some features, maybe
Thomas Heller could release "ctypes2" to tide us over until Python 2.6. But
I think ctypes as it will appear in Python 2.5 is already excellent.

> But, ultimately, it works fine now.  I don't know what is really gained
> by applying an argtypes to a function call anyway --- some kind of
> "type-checking".  Is that supposed to be safer.

Yes, type-checking mostly. Some interesting things might happen when you're
passing structs by value. But hopefully it just works.
 
> For NumPy extension modules, type checking is only a small part of the
> memory-violation danger.  In-correct array bounds and/or striding is far
> more common - not-to mention unaligned memory areas and/or unwriteable
> ones (like a read-only memory-mapped file).

Agreed.
 
> Thus, you're going to have to write a small "error-checking" code in
> Python anyway that calls out to the C-library with the right
> arguments.   So, basically you write an extension module that calls
> c-code just as you did before, but now the entire "extension" module can
> all be in Python because the call to an arbitrary C-library is made
> using ctypes.

Exactly. And once you have your DLL/shared library, there is no need to
compile anything again. Another useful benefit on Windows is that you can
build your extension in debug mode without having to have a debug build of
Python. This is very useful.
 
> <snip>
 
> Frankly, I'm quite impressed with the ease of accessing C-code available
> using c-types.   It quite rivals f2py in enjoyment using it.

Indeed. Viva ctypes!

> <snip>

Regards,

Albert