[Numpy-discussion] Ctypes support in NumPy
fullung at gmail.com
Mon Jul 3 02:48:54 CDT 2006
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.
> 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
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).
> 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.
> 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!
More information about the Numpy-discussion