继续测试ctypes的用法：
下载ctypes，安装好。

先把刚才的静态test.o编译成动态链接库：
=>gcc -shared test.o -o test.so

然后=>python
>>> from ctypes import *
>>> libt = CDLL("test.so")
>>> libt

>>> a= libt.tadd(1, 3)
>>> print a
4

哇哇，好像更加方便了。

总结：
两者都是扩展了python调用外部lib途径。好像pyrex更强调调用静态的lib，而且是把lib编译成python自己原生的module。
为了做到这个，除了有lib的.a文件外，必须要有lib的.h文件。
ctypes则是显示的调用动态的lib，只要有lib的.so,.dll就可以，目前ctypes已经成为2.5的内部module。
而pyrex还有一个比较重要特点就是可以用类c的语法写python的moduele。

比较同意这个观点：
> 我觉得 Pyrex 主要是用来为 c 库 提供一个 pythinic 的接口，而非优化python程序。

目前的例子非常简单，复杂情况下的调用有可能出现的问题都还没有碰到。Zoom给的文章里说到的复杂的结构，联合的情况
也还没有尝试。

想到要调用的lib的线程，指针，内存块操作，就有点头痛。
初步还是决定采用ctypes的方式，工作量上要少写一点东西，至少调试的时候也更直接一点。

一切都根据实际情况来做吧，要试错。

> >
> > Pyrex 是自动将Python 脚本转化为可编译的C 代码，以便高效执行和被C程序调用；
> >
> 
> 我觉得 Pyrex 主要是用来为 c 库 提供一个 pythinic 的接口，而非优化python程序。
> 
> -- 
> http://codeplayer.blogspot.com/

-- 
feihu <feihu.list在gmail.com>

feihu wrote:
>
>
> 总结：
> 两者都是扩展了python调用外部lib途径。好像pyrex更强调调用静态的lib，而且是把lib编译成python自己原生的module。
> 为了做到这个，除了有lib的.a文件外，必须要有lib的.h文件。
> ctypes则是显示的调用动态的lib，只要有lib的.so,.dll就可以，目前ctypes已经成为2.5的内部module。
> 而pyrex还有一个比较重要特点就是可以用类c的语法写python的moduele。
>
>   
是主要特点, 没有这个pyrex就不是pyrex了. 如果单纯为了包装已经写好的c
library, 还是用swig或boost.python比较好.
> 比较同意这个观点：
>   
>> 我觉得 Pyrex 主要是用来为 c 库 提供一个 pythinic 的接口，而非优化python程序。
>>     
>
>   
这个用swig包装c库, 然后再写一个纯python模块来提供pythonic接口会更省事.
pyrex主要不是为了做这个设计的.