Changes between Version 4 and Version 5 of python_C

Show
Ignore:
Timestamp:
02/06/2007 04:03:35 PM (4 years ago)
Author:
rowen
Comment:

Added a discussion and more links

Legend:

Unmodified
Added
Removed
Modified

  • python_C

    v4 v5  
    11Options for interfacing python to C/C++ libraries include the following. This is not a complete list and I don't have much information on the items, it's just intended to start a discussion. 
    22 
    3  * SWIG: powerful, but somewhat hard to use. It is under active development. 
     3 * [http://www.swig.org/ SWIG]: powerful, but somewhat hard to use. It is under active development. 
    44 
    5  * Boost Python: reportedly easy to use for interfacing to C++ libraries, but also reportedly results in slow compilation and fat libraries due to instantiating all possible templates. Does not appear to be under active development. 
     5 * [http://www.riverbankcomputing.co.uk/sip/ SIP]: developed to support !PyQt. One older published test showed it much faster than SWIG or Boost Python. Actively maintained. 
    66 
    7  * [http://www.riverbankcomputing.co.uk/sip/ SIP]: developed to support !PyQt. One published test showed it much faster than SWIG or Boost. Actively maintained. 
     7 * [http://www.boost.org/libs/python/doc/ Boost Python]: designed for interfacing to C++ libraries. Reportedly results in slow compilation and fat libraries due to instantiating all possible templates. Does not appear to be under active development. 
    88 
    9  * CXX 
     9 * [http://sourceforge.net/projects/cxx/ CXX]: a set of classes to help create extensions of Python in the C++ language. I don't know anything further. 
    1010 
    11  * ctypes: built into python and easy to use (much easier than SWIG because no compilation is required), but only interfaces to C, not C++ 
     11 * [http://python.net/crew/theller/ctypes/ ctypes]: built into python and very easy to use. However it only interfaces to C, not C++ so will be of limited use for LSST. 
    1212 
    13  * [http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]: reportedly easy to use, but appears to only wrap C, not C++ 
     13 * [http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ Pyrex]: reportedly very easy to use, but only wraps C, not C++ 
    1414 
    15 SWIG is probably our best choice, but SIP is worth investigating. ctypes is a reasonable alternative for interfacing to 3rd party C libraries. 
     15Discussion: 
     16 * Here is an interesting [http://people.web.psi.ch/geus/talks/europython2004_geus.pdf comparison] (pdf) of SWIG, Boost Python, SIP and Babel by Ola Skavhaug, et. al. from 2004. It gives a sense of relative complexity and performance. At that time SIP was significantly faster than SWIG or Boost Python. 
     17 * In a recent [http://thread.gmane.org/gmane.comp.python.scientific.user/10167/focus=10167 discussion] of this topic on a scipy mailing list, two people felt Boost Python was elegant but not a good idea in practice and one of those recommended SWIG instead. No alternatives were mentioned except a brief mention of [http://wlav.web.cern.ch/wlav/pyroot/ PyRoot] as a source of ideas. 
    1618 
    17 There was an interesting [http://thread.gmane.org/gmane.comp.python.scientific.user/10167/focus=10167 discussion] on the scientific python users group. It did not cover all options, but concluded that SWIG was preferable. 
     19Unless someone comes up with more information, I suggest we stick with SWIG and also allow ctypes for interfacing to 3rd party C libraries. 
     20 
     21As an aside [http://www.scipy.org/Weave weave] package may also be of interest in a few cases to avoid the need for an external C++ library in the first place. It allows one to include short bits of C++ code directly in python.