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 Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/numpy-discussion
