因为项目需要，需要优化已有的Python代码。目前Python代码的执行过程是将Python代码转变成一行行指令，然后解释器解释指令的执行，调用到C代码层。如果去掉指令解释这个阶段，直接进入C代码层，效率就比较高了。如果用之前所述的使用Python C API将Python代码改造为C代码并作为Python的内建模块，工作量极其大，也不能保证其正确性，所以这种方法不太现实。而Cython库正好符合这种场景需求，将已有的Python代码转化为C语言的代码，并作为Python的built-in模块扩展。
版本说明：
Python 2.7.13 (CPython)
Cython 0.25.2
Python的文件类型介绍：
.py python的源代码文件
.pyc Python源代码import后，编译生成的字节码
.pyo Python源代码编译优化生成的字节码。pyo比pyc并没有优化多少，只是去掉了断言
.pyd Python的动态链接库(Windows平台)
.py, .pyc, .pyo 运行速度几乎无差别，只是pyc, pyo文件加载的速度更快，不能用文本编辑器查看内容，反编译不太容易
本文的目标是将test.py文件生成test.c文件，然后将test.c文件作为Python源码的一部分，重新编译生成Python，使用时直接import test即可使用test模块。
Cython基本介绍：
文档中这样总结Cython:
Cython is an optimising static compiler for both the Python programming language and the extended Cython programming language (based on Pyrex). It makes writing C extensions for Python as easy as Python itself.
是一个Python编程语言的编译器，写C扩展就像写Python代码一样容易。
其最重要的功能是：
- write Python code that calls back and forth from and to C or C++ code natively at any point.
即 将Python代码翻译为C代码。之后就可以像前面文章介绍的C语言扩展Python模块使用这些C代码了。
Cython基本用法：
在使用Cython编译Python代码时，务必要安装C/C++编译器，本文是直接安装了Visiual Studio 2015的开发环境。
1. 安装Cython库
pip install Cython
就是如此简单明了
2. 编写一个测试代码文件test.py放在D:/test/test.py
def say_hello():
print "hello world"
然后在同一目录下，新建一个setup.py文件，内容如下：
from distutils.core import setup
from Cython.Build import cythonize
setup(ext_modules = cythonize("test.py"))
cythonize()是Cython提供将Python代码转换成C代码的API，
setup是Python提供的一种发布Python模块的方法。
3. 使用命令行编译Python代码：
python setup.py build_ext --inplace
如果出现这种情况是因为没有C编译器相关的配置没有设置好，在Windows上一般采用Microsoft VisualStudio，不同的VS版本设置不同。
- Visual Studio 2010 (VS10): SET VS90COMNTOOLS=%VS100COMNTOOLS%
- Visual Studio 2012 (VS11): SET VS90COMNTOOLS=%VS110COMNTOOLS%
- Visual Studio 2013 (VS12): SET VS90COMNTOOLS=%VS120COMNTOOLS%
- Visual Studio 2015 (VS14): SET VS90COMNTOOLS=%VS140COMNTOOLS%
- Visual Studio 2017 (VS14): SET VS90COMNTOOLS=%VS150COMNTOOLS%
这里采用VS2015作为C的编译器。
在命令行中输入SET VS90COMNTOOLS=%VS140COMNTOOLS%
然后输入编译命令：python setup.py build_ext --inplace
最终的生成结果如下:
在D:/test/ 目录中：
test.c是test.py转化后的C代码文件，可以看到test.c非常大！！
test.pyd是python的动态链接库，我们在使用import test时会加载
build目录编译过程中生成的临时文件
使用刚刚生成的test模块，就像使用Python的任意模块一样：
这里稍微解释一下 命令行：python setup.py build_ext --inplace
build_ext是指明python生成C/C++的扩展模块(build C/C++ extensions (compile/link to build directory))
--inplace指示 将编译后的扩展模块直接放在与test.py同级的目录中。
整个Cython工作的流程如下图所示：
分两步：
1）.py文件使用Cython被编译为.c文件；
2）.c文件使用C编译器生成.pyd(windos)或.so(linux)文件。
除了这种普遍的用法外，还可以在Python代码的某些地方加上静态类型声明，也可以更进一步提升Python的运行效率，这些属于小技巧了~
比如：
def say_hello(int s):
cdef int a = 2
print s + 2
s和a变量直接指示为int类型，不用再做动态语言的类型推断了。
小测试：
import math
import time
def f():
time1 = time.time()
for i in range(100000000):
x = math.sqrt(i)
time2 = time.time()
print time2 - time1
这段原生的Python代码运行时间是13.17秒，使用Cython优化后，运行时间为9.36秒。基本上提升30%。其实Cython一般对外声称的效率提升也大概是这么多。
Cython中的坑
在这一小节中，讨论Cython中的一些坑以及填坑姿势。Cython官方文档中已经明确指出一些不支持的Python特性，有些不打算修复，再结合具体项目场景，给出一些坑的解决方案。
具体项目需求： 将一些需要优化的Python代码模块翻译成C代码，加入项目中，编译链接之后，作为Python的一个built-in模块。
所以，只需要转换成C代码这一步骤即可，不需要使用Python提供的distutils模块，只需要Cython提供的cythonize。
1. 从Python的site-package中提取install的Cython目录，独立出来。因为是供给其他人使用，其他人pip install cython的话可能版本不一致，会出现一些问题。
Cython目录是Cython源码以及Python2.7/Lib/site-package下的cython.py，即：
CythonTool是封装了转化为C代码的py脚本文件。
在使用时，需要设置一下sys.path，在import时才能找到我们独立出来的Cython模块。
# import Cython path sys.path.insert(0, cython_path) from Cython.Build import cythonize from Cython.Compiler import Options
在sys.path的头部添加cython_path，所以Python site-package里的Cython就不会影响我们独立出来的Cython模块。
2. 在编译python代码为C代码时，需要指定输出的C代码文件路径，Cython默认的是python脚本目录，这样会导致py文件与.c文件混在一起，很容易就乱了。
目前工作目录有三个
LibDir: 需要优化的Python脚本所在目录
CfileDir: 输出的C代码文件所在的目录
ToolDir: 封装的cython优化脚本所在的目录，其作用是将LibDir中的Python模块转换为C代码，然后输出到CfileDir
故而封装的cython脚本工作目录在ToolDir，脚本中最核心的是代码是：
cythonize(pyfilePath, build_dir=CfileDir)
使用build_dir参数指明C代码输出目录。
看起来很完美，但是Cython源码在这里里有个坑。
当指定build_dir时，当pyfilePath与CfileDir都为绝对路径时，且cython脚本的工作目录与pyfilePath不一致时，cythonize会将输出文件的目录置为pyfilePath所在的目录，故最后输出的Ｃ代码文件不会到CfileDir里。
所以应该在封装的cython脚本里调用os.chdir(LibDir)，转换完成时再切换到原有工作目录。牢记cython的工作目录应该与待优化的python脚本目录一致。
原因：cythonize中的实现有这样一段代码：【调试状态下】
红色框中，如果c_file是一个绝对文件名时，会出现以下情况，至于c_file为什么会是一个绝对的文件名，是因为cython的工作目录与待优化脚本目录不匹配导致的。
3. 原始的Cython对Python的Package支持度不够，一个大坑！！
只能通过修改Cython的源码来填坑。
原始的Cython编译Python之后，生成的C代码里有两个关键的地方，拿test模块为例：
这里定义了test模块初始化函数，这个函数里会有创建test模块的代码部分：
当import时，Python解释器会调用这里，初始化test模块，将test名字加入到sys.builtin_module_names中。
测试发现，如果有D:/Lib/mypackate/test.py ， 编译后，生成的C代码与D:/Lib/test.py生成的代码并无不同，即mypackate这个包被忽略了，导致生成的C代码没有了包依赖关系。
顺着代码阅读，最终确定了问题出现的源头，Cython/Compiler/ModuleNode.py， 修改了此文件中的两个函数：
1）生成模块init代码函数：full_module_name替换掉env.module_name， 即用initmypackage_test替换init_test
2) 修改了创建模块时传入的模块名规则，并考虑到mypackage/__init__.py这种情况， 对于package来说需要加入__path__用以标识这个对象不是普通的Python模块，而是一个包。
4. 深坑。 inspect、types相关。
Inspect模块中有各种类型判断函数,比如 isfunction, ismethod, ismodule等。这里的坑是：
cython化的函数类型变为了cython_function_or_method，而原始python的函数类型是function，所以如果待优化的Python脚本中使用isfunction(func, types.FunctionType)时，如果func是原始的函数则返回True,而cython化的函数返回False. 除了function类型外还有generator, functionType.func_globals类型也存在不一致。
目前在inspect.py的isfunction中加入了trick,会判断
type(func).__name__=="cython_function_or_method". 并且types.py模块不被cython化，那么如果调用inspect.isfunction(func, types.FunctionType)对于原始的Python函数还是cython化的函数都没有问题了。
但是如果直接使用isinstance(func, types.FunctionType)仍然会存在问题，types.FunctionType只对原始的python函数判断正确。
比较绕，总而言之一句话，python里的类型和cython化后的对应的类型可能会不同。我总结了大部分python类型，其中有几个cython化后类型不一致：
没有什么太好的解决办法，要么改写inspect模块，但还要保证Python代码不能直接使用types模块，要么修改Python源码中关于isinstance的实现。
5. 官方文档中列出的坑
1） 不支持Nested tuple， Python2中的特性，Python3不支持了。所以Cython直接不支持Nested tuple特性
2）找不到变量名：You can disable the latter behaviour by setting "error_on_unknown_names" to
解决办法：
3）Stack Frames.
Cython不支持Stack Frame。
总结：可以考虑使用Cython优化一些简单的Python项目，如果用到非常复杂的场景的话，有些语法的特性不支持，会有绕不过去的坑
参考资料：
https://github.com/cython/cython
https://mdqinc.com/blog/2011/08/statically-linking-python-with-cython-generated-modules-and-packages/