我想从Python应用程序调用C库。我不想包装整个API,只包装与我的案例相关的函数和数据类型。在我看来,我有三个选择:

用c语言创建一个实际的扩展模块,这可能有点过分,而且我还想避免学习编写扩展的开销。 使用Cython将相关部分从C库公开到Python。 在Python中完成所有的事情,使用ctypes与外部库通信。

我不知道2)还是3)哪个更好。3)的优点是ctypes是标准库的一部分,生成的代码将是纯Python——尽管我不确定这个优点到底有多大。

这两种选择有更多的优点/缺点吗?你推荐哪种方法?


编辑:感谢你的回答,它们为任何想做类似事情的人提供了很好的资源。当然,这个决定仍然是针对单一情况做出的——没有一个“这是正确的事情”之类的答案。对于我自己的情况,我可能会使用ctypes,但我也期待在其他一些项目中尝试Cython。

由于没有唯一的正确答案,接受一个答案就有些武断了;我选择了FogleBird的答案,因为它提供了一些关于ctypes的很好的见解,而且它也是目前投票最多的答案。然而,我建议阅读所有的答案,以获得一个良好的概述。

再次感谢。


当前回答

要从Python应用程序调用C库,还有cffi,这是ctypes的新替代方案。它为FFI带来了全新的面貌:

它以一种迷人的、干净的方式处理问题(与ctypes相反) 它不需要编写非Python代码(如SWIG, Cython,…)

其他回答

当你已经有一个编译好的库blob要处理(比如OS库)时,ctypes非常有用。然而,调用开销很严重,所以如果您将对库进行大量调用,并且无论如何都要编写C代码(或者至少编译它),那么我建议您使用cython。这并不需要做更多的工作,而且使用生成的pyd文件会更快、更python化。

我个人倾向于使用cython来快速加速python代码(循环和整数比较是cython特别擅长的两个领域),当涉及到其他库的一些更复杂的代码/包装时,我将转向Boost.Python。提振。Python的设置可能很挑剔,但一旦你让它工作了,它就可以简单地包装C/ c++代码。

cython在包装numpy方面也很出色(这是我从SciPy 2009会议中了解到的),但我没有使用过numpy,因此不能对此进行评论。

有一个问题让我使用ctypes而不是cython,这在其他答案中没有提到。

Using ctypes the result does not depend on compiler you are using at all. You may write a library using more or less any language which may be compiled to native shared library. It does not matter much, which system, which language and which compiler. Cython, however, is limited by the infrastructure. E.g, if you want to use intel compiler on windows, it is much more tricky to make cython work: you should "explain" compiler to cython, recompile something with this exact compiler, etc. Which significantly limits portability.

警告:以下是Cython核心开发人员的观点。

I almost always recommend Cython over ctypes. The reason is that it has a much smoother upgrade path. If you use ctypes, many things will be simple at first, and it's certainly cool to write your FFI code in plain Python, without compilation, build dependencies and all that. However, at some point, you will almost certainly find that you have to call into your C library a lot, either in a loop or in a longer series of interdependent calls, and you would like to speed that up. That's the point where you'll notice that you can't do that with ctypes. Or, when you need callback functions and you find that your Python callback code becomes a bottleneck, you'd like to speed it up and/or move it down into C as well. Again, you cannot do that with ctypes. So you have to switch languages at that point and start rewriting parts of your code, potentially reverse engineering your Python/ctypes code into plain C, thus spoiling the whole benefit of writing your code in plain Python in the first place.

With Cython, OTOH, you're completely free to make the wrapping and calling code as thin or thick as you want. You can start with simple calls into your C code from regular Python code, and Cython will translate them into native C calls, without any additional calling overhead, and with an extremely low conversion overhead for Python parameters. When you notice that you need even more performance at some point where you are making too many expensive calls into your C library, you can start annotating your surrounding Python code with static types and let Cython optimise it straight down into C for you. Or, you can start rewriting parts of your C code in Cython in order to avoid calls and to specialise and tighten your loops algorithmically. And if you need a fast callback, just write a function with the appropriate signature and pass it into the C callback registry directly. Again, no overhead, and it gives you plain C calling performance. And in the much less likely case that you really cannot get your code fast enough in Cython, you can still consider rewriting the truly critical parts of it in C (or C++ or Fortran) and call it from your Cython code naturally and natively. But then, this really becomes the last resort instead of the only option.

所以,ctypes很适合做简单的事情,并快速运行一些东西。但是,当事情开始发展时,您很可能会注意到最好从一开始就使用Cython。

就我个人而言,我会用C写一个扩展模块。不要被Python C扩展吓倒——它们写起来一点都不难。文档是非常清晰和有用的。当我第一次用Python写一个C扩展时,我想我花了大约一个小时来弄清楚如何写一个——根本没有多少时间。

ctypes是您快速完成它的最佳选择,并且在您仍然在编写Python时使用它是一种乐趣!

我最近包装了一个使用ctypes与USB芯片通信的FTDI驱动程序,它很棒。我在不到一个工作日的时间里完成了所有的工作。(我只实现了我们需要的函数,大约15个函数)。

我们以前使用第三方模块PyUSB来实现同样的目的。PyUSB是一个实际的C/Python扩展模块。但是PyUSB在阻塞读/写时没有释放GIL,这给我们带来了问题。因此,我使用ctypes编写了自己的模块,它在调用本机函数时释放GIL。

需要注意的一点是,ctypes不知道你正在使用的库中的#define常量和其他东西,只知道函数,所以你必须在自己的代码中重新定义这些常量。

下面是代码最终的样子的一个例子(很多东西被剪掉了,只是想向你展示它的要点):

from ctypes import *

d2xx = WinDLL('ftd2xx')

OK = 0
INVALID_HANDLE = 1
DEVICE_NOT_FOUND = 2
DEVICE_NOT_OPENED = 3

...

def openEx(serial):
    serial = create_string_buffer(serial)
    handle = c_int()
    if d2xx.FT_OpenEx(serial, OPEN_BY_SERIAL_NUMBER, byref(handle)) == OK:
        return Handle(handle.value)
    raise D2XXException

class Handle(object):
    def __init__(self, handle):
        self.handle = handle
    ...
    def read(self, bytes):
        buffer = create_string_buffer(bytes)
        count = c_int()
        if d2xx.FT_Read(self.handle, buffer, bytes, byref(count)) == OK:
            return buffer.raw[:count.value]
        raise D2XXException
    def write(self, data):
        buffer = create_string_buffer(data)
        count = c_int()
        bytes = len(data)
        if d2xx.FT_Write(self.handle, buffer, bytes, byref(count)) == OK:
            return count.value
        raise D2XXException

有人对不同的选项做了一些基准测试。

我可能会更犹豫,如果我必须包装一个c++库与许多类/模板/等。但是ctypes可以很好地使用结构,甚至可以回调到Python。