On May 30, 2008, at 3:20 PM, Lisandro Dalcin wrote: > On 5/30/08, rahul garg <[EMAIL PROTECTED]> wrote: >> I am a little curious about ctypes. Have you looked at ctypes and >> what >> advantages/disadvantages do you think it has over SWIG and Cython for >> wrapping the libraries you are interested in? Of course ctypes >> doesnt work >> for C++ but any other specific problems? > > Well, a C library API is not just functions and data exported by the > linker. It is also #define'd macros, typedef'd stuff, custom C structs > with many slots. If you want to write a full featured wrapper to a > complex library, the ctypes way is going to be even more painfull than > SWIG or Cython. > > Suppose you want to access, in the MPI case, MPI_COMM_WORLD. Look at > the header files of major's MPI out there (MPICH2, OpenMPI, HP MPI, > IBM MPI): in all cases MPI_COMM_WORLD is a #defined thing, in some > case an integer, in other a pointer. And that applies to all MPI > predefined handles (operations, datatypes, etc,) and other stuff. You > just cannot access and manage a full C API in ctypes; at least, I do > not know how to handle that. > > For example, the new Cython-based mpi4py can be build against Python > version ranging from 2.3 to 3.0 (yes, it is Py3K ready!), and with all > major MPI's out there, either if they are MPI-1 or MPI-2 > implementation, in Linux, Mac OS X, and Windows. I'll never buy the > ctypes way until someone can show me that this degree of portability > is possible. Even if someone can do this with ctypes, I guess such a > code would not be easy to understand and maintain. > > For the case of petsc4py, the same comments apply. PETSc C API do have > macros. Furthermore, it's API changes from release to release (PETSc > developers does not bother from backward compatibility issues). But > petsc4py, either the former SWIG-based or the newer Cython-based, can > be used with petsc-2.3.2, petsc-2.3.3, or the latest development copy. > All this with a layer of compatibility functions and macros. How in > the hell a serious developer is going to handle all that with ctypes?? > > Please note that I do not have nothing against ctypes. It is a > wonderful and very good tool, but you cannot use it in all scenarios. > However, if the libraries are all C functions, and they do not use > macros in any way, then ctypes is still a good option, no compilation > needed, pure python code. Of course, be prepared to get a segfault > from time to time, not because of a ctypes bug, but because of your > bugs.
Very good summary. Also, I would like to note that if you're actually using (rather than just wrapping) a C library then ctypes will be vastly slower. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
