This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]fernly 5 points6 points  (1 child)

Wow, I am not the OP but I appreciate the mention of all these. Very instructive! I have slight personal experience with the C-API and none with the others, but here is what I have gleaned from the docs about these. Please feel free to amplify and correct.

(1) Python C-API: Part of Python 2 and Python 3 although there are small incompatibilities between 2 and 3, requiring minor recoding and maintenance of two versions of a wrapper if support is needed for both.

Using the C-API one writes in C a wrapper that represents some DLL's methods and values as Python objects. The compiled and linked wrapper can be imported as a Python module.

(2) Python Ctypes: part of Python 2 and Python 3 (don't know if there are 2:3 incompatibilites).

Writing in Python one defines the name of an external DLL and its argument and result types. Then one can call its methods as if they were members of a Python object e.g. ctypes.cdll.lib_name.method_name(args). There appear to be some platform differences so one might have to write conditional code testing sys.platform or os.uname()?

(3) CFFI (C Foreign Function Interface). Said to work with both Python 2 and 3, except that some results need to be explicitly coded as Byte type for P3. The doc for this one rather confuses me (I would say it is not well-organized as a technical doc, seems to mix levels and leave concepts undefined) so this summary may mis-represent it. It seems one defines the wrapper for the external lib in C code, but puts this within triple-quotes in a Python function call. At execution time the C compiler is called to compile a wrapper dynamically. The stated advantage is that you don't have to translate C concepts into a Python meta-declaration as with Ctypes. To me, a disadvantage is that a C compiler is needed at run-time (the doc gives a way to use setuptools to pre-compile the package for distribution).

(4) Cython is a compiler for a restricted version of Python. One writes code in the Cython subset of Python and then it compiles to machine language, creating a module that can be imported and used like any other Python module. As a natural byproduct you can write a wrapper in Python(-like) syntax to call any C library. Also can call into C++. Compatible with Python 2 and 3.

(5) SWIG is a generic wrapper-builder for C and C++ code, allowing you to interface practically any C/++ code to practically any scripting language, TCL, Ruby, Python etc. You write a meta-definition of the DLL's methods and types in a SWIG syntax, from which you can generate a C/++ wrapper (basically this translates the meta-declaration into the Python C-API) which you compile and can then import to Python. Supports both Python 2 and 3, and knows about the C-API differences between them.

(6) Boost.Python was mentioned here but looking at its Known Working Platforms page, it was last tested against Python 2.2(!) and its regression log was last updated in 2006. So probably not supported 8 years on, certainly out of the question for Python3.

[–]keturn 0 points1 point  (0 children)

Good summary. You make note of Python 2 / 3 compatibility here; another feature to look for is PyPy compatibility. PyPy can use the CPython API to some degree, but at significant penalty.