北京建设部网站职称,集约化网站建设方案,平面设计提升培训中心,网站加速工具作者#xff1a;折木奉太郎(经授权转载)来源#xff1a;https://www.zhihu.com/question/30296617/answer/112564303作为 Python 爱好者#xff0c;需要了解 .py 脚本的基本运行机制及特性#xff1a;在很多工作上#xff0c;Python 的运行流程基本上取决于用户#xff0… 作者折木奉太郎(经授权转载)来源https://www.zhihu.com/question/30296617/answer/112564303作为 Python 爱好者需要了解 .py 脚本的基本运行机制及特性在很多工作上Python 的运行流程基本上取决于用户因此源码不需要编译成二进制代码(否则无法实现大部分贴近用户的特性)而直接从源码运行程序。当我们运行 Python 文件程序的时候Python 解释器将源码转换为字节码然后再由解释器来执行这些字节码。因此总的来说它具有以下三条特性源码距离底层更远(根据官方文档的解释。不说你们也感觉得到)(。・ω´・)运行时都需要生成字节码交由虚拟机执行。(你们问我虚拟机在哪儿你们也不看看各自都是用什么软件执行的没错就是解释器别和我说是 IDLE 啊。虚拟机具体实现了由 switch-case 语句构成的框架函数 PyEval_EvalFrameEx刚刚说的字节码就是这货执行的)每次执行脚本虚拟机总要多出加载和链接的流程。(所以呢相比于编译型语言就有点慢了。这与“有丝分裂间期”一样准备东西也要花时间啊)那么有人要问了“不是说运行时总要生成字节码么那字节码都去哪儿了” 咳咳别急容我先说说虚拟机它是怎么执行脚本的(咕噜咕噜喝杯水...)完成模块的加载和链接将源代码翻译为 PyCodeObject 对象(这货就是字节码)并将其写入内存当中(方便 CPU 读取起到加速程序运行的作用)从上述内存空间中读取指令并执行程序结束后根据命令行调用情况(即运行程序的方式)决定是否将 PyCodeObject 写回硬盘当中(也就是直接复制到 .pyc 或 .pyo 文件中)之后若再次执行该脚本则先检查本地是否有上述字节码文件。有则执行否则重复上述步骤。你看在我们点击(或输入命令)运行脚本并悠闲地喝咖啡时“人家”虚拟机做了这么多的事情。不过你有没有发现 .pyc 或 .pyo 文件是否生成是取决于我们如何运行程序的(虽然我们不知道要怎么做(ง •̀_•́)ง )。同样有人会吐槽“哼为什么不直接生成这些文件这样来得不是‘更快、更高、更强’”其实虚拟机也是讲究效率的。毕竟对于比较大的项目要将 PyCodeObject 写回硬盘也是不可避免地要花些时间的而且它又不知道你是不是也就只执行一次之后就对刚刚跑完的脚本“弃之不顾”了呢。不过它其实也有贴心的一面。比如若你在命令行直接输入“python path/to/projectDir”(假设projectDir目录含有“__main__.py”文件以及其他将要调用的模块)那么程序运行结束后便自动为当前目录下所有的脚本生成字节码文件并保存于本地新文件夹__pycache__当中。(这也有可能是 IDE 写小项目时自动生成 .pyc 文件的原因不过问题描述略微暧昧。详情参见上面知乎问题板块)或者是在命令行输入“python path/to/projectDir/__main__.py”则生成除__main__.py 外脚本的字节码文件。不过总的来说上述这两种行为都大大缩短了项目运行前的准备时间(毕竟分工明确的程序规模应该不会太小复用率也不会太低。除非吃饱了撑着搞出这么多事情(Θ皿Θメ))模块在每次导入前总会检查其字节码文件的修改时间是否与自身的一致。若是则直接从该字节码文件读取内容否则源模块重新导入并在最后生成同名文件覆盖当前已有的字节码从而完成内容的更新(详见import.py)。这样就避免了修改源代码后与本地字节码文件产生冲突(当然设计者也不会这么傻。╮(▽)╭)。若想优化生成字节码应注意这两点.pyc 文件是由 .py 文件经过编译后生成的字节码文件其加载速度相对于之前的 .py 文件有所提高而且还可以实现源码隐藏以及一定程度上的反编译。比如 Python3.3 编译生成的 .pyc 文件Python3.4 就别想着去运行啦→_→.pyo文件也是优化(注意这两个字便于后续的理解)编译后的程序(相比于 .pyc 文件更小)也可以提高加载速度。但对于嵌入式系统它可将所需模块编译成 .pyo 文件以减少容量。但总的来说作用上是几乎与原来的 .py 脚本没有区别的也就是“然并卵 ”(当然并非毫无作用。比如我个人觉得用处最大的地方就是防止别人偷看我的代码。_(:з」∠)_毕竟 .py 源文件是直接以源码的形式呈现给大家的)。╮(╯▽╰)╭ 呃...这么说好像又有点自相矛盾的赶脚。在所有的 Python 选项中-O表示优化生成 .pyo 字节码(这里又有“优化”两个字得注意啦)-OO表示进一步移除 -O 选项生成的字节码文件中的文档字符串(这是在作用效果上解释的而不是说从 -O 选项得到的文件去除)-m表示导入并运行指定的模块对此我们可以使用如下格式运行 .py 文件来生成 .pyc 文件(以下调用均假设 /path/to目录含有.py 脚本)python -m py_compile /path/to/需要生成.pyc的脚本.py #若批量处理.py文件#则替换为/path/to/{需要生成.pyc的脚本1,脚本2,...}.py#或者/path/to/其效果等效于如下代码import py_compilepy_compile.compile(r/path/to/需要生成.pyc的脚本.py) #同样也可以是包含.py文件的目录路径#此处尽可能使用raw字符串从而避免转义的麻烦。比如这里不加“r”的话你就得对斜杠进行转义py_compile 是 Python 的自带模块这里面就两个函数(看到这个我笑了(๑•́ ₃ •̀๑)噗噗)。其下的 py_compile.compile(file[, cfile[, dfile[, doraise]]]) 可将 .py 文件编译生成 .pyc 文件(默认)对应的参数解释如下file表示需要生成 .pyc 或 .pyo 文件的源脚本名(字符串)cfile表示需要生成 .pyc 或 .pyo 文件的目标脚本名。呃...好像没有区别(﹏) 也就是源脚本-----[巴拉拉赐予你力量编译]( *▽)o ─═≡※:☆-----目标脚本。当然它默认是以 .pyc 为扩展名的路径名的字符串(呼...好长)。此外当且仅当所使用的解释器允许编译成 .pyo 文件才能以“.pyo”结尾。这也就是我上面为什么会在函数功能解释上加上“(默认)”这两个字的原因。dfile表示编译出错时将报错信息中的名字“file”替换为“dfile”。doraise设置是否忽略异常。若为 True则抛出 PyCompileError 异常否则直接将错误信息写入 sys.stderr(什么不知道 sys.stderr温馨提示sys.stderr 是 Python 自带的标准错误输出)(╯ - )╯︵ ┻━┻ (掀桌子) ┬─┬ ノ( - ノ) (摆好摆好) (╯°Д°)╯︵ ┻━┻(再TA喵掀一次)另外生成 .pyo 文件的格式调用如下python -O -m py_compile /path/to/需要生成.pyo的脚本.py那么有人要问了为什么不是像生成.pyc文件那样采用“python -O /path/to/需要生成.pyo的脚本.py”形式的调用“忘记”说明这一点了很多博客以及书籍都像我上面那样解释“-O”选项的作用但详细来解释的话是:-O 选项将 .pyc 文件优化(注意我一直强调的“优化”二字这里就用到啦)为 .pyo 文件而不是将 .py 文件优化编译为 .pyo 文件。(其直接的结果是优化编译后的文件略微小于 .pyc 文件也就是“减肥”了。现在大家知道 .pyo 文件为什么小的原因了吧)注意 以上无论是生成 .pyc 还是 .pyo 文件都将在当前脚本的目录下生成一个含有字节码的文件夹 __pycache__ 。可能还有人会问.pyd 文件又是什么鬼(﹏)(问题真多精分ing...) 别在意那只是 Python 的动态链接库。如果要深究还得扯上 C 的知识(长篇大论的会被喷的啊)。再啰嗦一句生成字节码的方法多了去了不止以上这几种。比如你们不妨试试将上面命令行调用中的“py_compile”改成“compileall”而代码行中的“py_compile.compile”改成“compileall.compile_file”或“compileall.compile_dir”又或者直接使用带有编译功能的 IDE 生成字节码。再再啰嗦一句知道 Python 运行机制并不是我们一般人所必须的(吃瓜群众“滚我刚好不容易看完了你才说”)。但是了解其加速程序运行以及优化代码的设计思想对于我们在日后构造缓存系统、如何减少不必要的运行时间以及同步更新工作内容等问题上起到很大的借鉴作用。若想要了解更多的内容可以去翻翻官方文档和其它博客https://docs.python.org/3.5/using/cmdline.html?highlight#command-line-and-environmenthttps://docs.python.org/3.5/library/py_compile.html?highlight.pyc#module-py_compilehttps://docs.python.org/3.5/c-api/code.html?highlightpycodeobject#code-objectshttp://nedbatchelder.com/blog/200804/the_structure_of_pyc_files.htmlhttp://www.tuicool.com/articles/Q7Rj6rrhttp://developer.51cto.com/art/201002/184914.html好文章我在看❤️
