python编译pyc和pyo文件(转)

原始出处:http://gmingzhe.blog.51cto.com/810664/163444

python并非完全是解释性语言,它是有编译的,先把源码py文件编译成pyc或者pyo,然后由python的虚拟机执行,相对于py文件来说,编译成pyc和pyo本质上和py没有太大区别,只是对于这个模块的加载速度提高了,并没有提高代码的执行速度,通常情况下不用主动去编译pyc文件,文档上说只要调用了import model那么model.py就会先编译成pyc然后加载

1. 如果需要特殊的单独编译,则只需要使用py_complie这个模块就行了,如下

import py*compile py*compile.compile(r'H:\game\test.py')

compile函数原型:

compile(file[, cfile[, dfile[, doraise]]])

file 表示需要编译的py文件的路径

cfile 表示编译后的pyc文件名称和路径,默认为直接在file文件名后加c 或者 o,o表示优化的字节码

dfile 错误消息保存的路径

doraise 可以是两个值,True或者False,如果为True,则会引发一个PyCompileError,否则如果编译文件出错,则会有一个错误,默认显示sys.stderr中,而不会引发异常

2. 如果要把一个文件夹下的所有py文件都进行编译,则用下面的命令

import compileall compileall.compile_dir(dirpath)

dirpath是我们要编译的文件夹的绝对路径

3. 如果要编译pyo文件则

编译成 pyo 就是在控制台执行

python -O -m py_compile file.py

其中file.py就是我们要编译的源文件

个人感觉这个原理知道就行了,其实没多大用处,仅仅提高了加载速度而已,另外还有一点好处就是可以减少文件的大小,可能对于嵌入式系统中把需要的模块都编译成pyo文件可减少容量,毕竟嵌入式系统多数都是容量有限,现在的pc硬件越来越强,仅仅提高加载速度没多大作用,不过这也是python的机理,它就是这么干活的,知道就好,呵呵

Windows下GTK中文显示问题

人算不如天算,竟然要在Python+GTK和VB.net之前选择了。

这里下载了PYGTK整合包安装完成后,发现运行后中文显示很丑陋,同时日志中显示如下信息:

PangoWarning: couldn't load font "瀹嬩綋 Not-Rotated 9", falling back to "Sans Not-Rotated 9", expect ugly output.

PangoWarning: couldn't load font "瀹嬩綋 9", falling back to "Sans 9", expect ugly output.

PangoWarning: couldn't load font "宋体 Not-Rotated 9", falling back to "Sans Not-Rotated 9", expect ugly output.

显然,上面的乱码应该是“宋体”,但没能正确识别。

解决办法是在etc\gtk-2.0\目录下新建一个gtkrc.zh_CN文件,其内容可以从gtkrc中复制一部分,再增加汉字使用的指定:

- 阅读剩余部分 -

firefox结合foxyproxy模式订阅功能让浏览更顺畅

工作用机上使用的是FireFox,重装没保存配置,发现忘记设置顺畅上网的一个链接了,就记在这吧。

  1. 装上foxyproxy扩展
  2. 设置好代理
  3. 在foxyproxy的pattern subscriptions中新增一个,订阅链接中设置为

http://autoproxy-gfwlist.googlecode.com/svn/trunk/gfwlist.txt

这个链接总是忘记。注意格式选择autoproxy,编码选择Base64,再把代理加入这个订阅中。

如图:

- 阅读剩余部分 -

[翻译]DSQL/BLR实现内幕

这是Adriano dos Santos Fernandes写在自己博客的一篇关于Firebird 的DSQL/BLR重构/重写的一些背景和实现内幕。

原文为:DSQL/BLR compilers internals

这个贴子的内容是一些原始笔记,没有研究过这些代码的人不太好理解。

说实话,以前DSQL/BLR的实现是如此恶心,以至于要实现改进对我也不是件容易的事(我一直从事这个事)。这需要多次的尝试和重新来过,但还好结果总是非常好。可以说,这是个花费许多时间的大工程,我也是现在才在这写些笔记。

回想2006,我刚被邀请从事DSQL方面工作时,我开始思考我们应该做些什么来改进DSQL和BLR的内部编译。我开始从

src/dsql/pass1.cpp

src/jrd/cmp.cpp

进行研究。那之前,增加一个简单的函数功能也是一个噩梦。下面的对话是Nickolay Samofatov 和我在2004年9月进行的:

Adriano: 我增加了“Lower”函数,我没想到这活这么麻烦。“Length”函数也要通过BLR加进来么?
Nickolay: 怎么会麻烦呢?
Nickolay: 只是调整15个左右的文件 :-) 

从那后我好几年都在调整“15个左右的文件”来增加每个功能,这过程非常烦人。在2.5版,为了实现 ALTER CHARACTER SET 和 AUTONOMOUS TRANSACTIONS 语句语法,我增加了“兼容层”来以更加面象对象的方式来实现这些语句语法。我在这个贴子中描述了DDL是如何工作的。

如我在那贴子中承诺的那样,这个功能将实现子函数,以及包(packages)功能。

在Firebird V3开发过程后,很显然,不仅是语句需要这个“兼容层”,表达式也是一样。而且表达式相比语句而言对于“兼容层”更加“感兴趣”。Firebird中有许多类型表达式,它们都错落地分布在dsqlnod/jrdnod结构和各类算法中(现在这个现象不存在了)。这些类型是:record sources, values, booleans, aggregate values, windowed values 和 lists。

表达式兼容层设计成实现window函数(更多信息请查看这里这里这里),但同时它产生了更多糟糕的内部接口代码。

完整地移除jrdnod很容易,并在很早以前就完成了。但dsqlnod还留着。它有许多代码需要完全重构(或重写),现在这些工作都完成了。

下面是Node类的继承关系。除了列表中的,每个都有自己的继承类(这里忽略了)。

Node
--- DdlNode
--- DmlNode
------ StmtNode
------ ExprNode
--------- BoolExprNode
--------- ValueExprNode
------------ AggNode
--------------- WinFuncNode
--------- RecordSourceNode
--------- ListExprNode
------------ ValueListExprNode
------------ RecSourceListExprNode

正如我所说过的,这里花费了大量的时间,但如果没有花费这些时间许多其它功能就不可能实现或无实现价值了。

现在可以轻松地说老代码是垃圾(这是事实,真的!),但许多事都是相关并逐渐演进的(C和C++,bison和btyacc)。重要的是返工的时机到了,所以这项工作就被完成了。