Python 之父撰文回忆：为何要创造 pgen 解析器？

花下猫语： 近日，Python 之父在 Medium 上开通了博客，并发布了一篇关于 PEG 解析器的文章（参见我翻的 全文译文）。据我所知，他有本身的博客，为何还会跑去 Medium 上写文呢？好奇之下，我就打开了他的老博客。

最后一篇文章写于 2018 年 5 月，好巧不巧，写的竟是 pgen 解析器，正是他在新文中无情地吐槽的、说将要替换掉的 pgen 。在这篇旧文里，Guido 回忆了他创造 pgen 时的一些考量，在当时看来，创造一个新的解析器无疑是明智的，只不过期过境迁，如今有了更好的选择罢了。

前不久，咱们聊过 Python 中 GIL 的移除计划、内置电池的“手术”计划 以及 print 的演变故事，现在，它的解析器也要迎来改造了。Python 这门语言 30 岁了，还可贵地保持着活力四射。就让咱们一块儿祝福它吧，愿将来更加美好。

本文原创并首发于公众号【Python猫】，未经受权，请勿转载。

原文地址：https://mp.weixin.qq.com/s/ovIiw7ZmXJM4qUSTGDk7kQ

---

原题 | The origins of pgen

做者 | Guido van Rossum（Python之父）

译者 | 豌豆花下猫（“Python猫”公众号做者）

原文 | https://python-history.blogspot.com/2018/05/the-origins-of-pgen.html

声明 | 翻译是出于交流学习的目的，欢迎转载，但请保留本文出处，请勿用于商业或非法用途。

David Beazley 在 US PyCon 2018 上的演讲，关于语法分析生成器（parser generators），提醒了我应该写一下关于它的历史。这是一个简短的脑转储（也许我从此会解释它）。

（译注：我大胆揣测一下“脑转储”吧，应该说的是，把我的的记忆以及 Python 的历史细节，转化成文字，这是个存储固化的过程，方便传承。而我作的翻译工做，就是把这份文档财富，普及给更多的 Python 爱好者。）

实际上，有两个 pgen，一个是最初的，用 C 语言写的，还有一个则是用 Python 重写的，在 lib2to3/pgen2 下面。

两个都是我写的。最先那个其实是我为 Python 编写的第一份代码。尽管从技术上讲，我必须首先编写词法分析程序（lexer）（pgen 和 Python 共用词法分析程序，但 pgen 对大多数标记符不起做用）。

之因此我要写本身的语法分析生成器，缘由是当时这玩意（我熟悉的）至关稀少——基本上就是用 Yacc（有个 GNU 的重写版，叫做 Bison（译注：美洲野牛），但我不肯定那时的本身是否知道）；或者是本身手写一个（这是大多数人所作的）。

我曾在大学里用过 Yacc，从“龙书”中熟悉了它的工做原理，可是出于某些缘由，我并不喜欢它；IIRC 关于 LALR(1) 语法的局限性，我很难解释清楚。

（译注：一、龙书，原文是 Dragon book，指代《Compilers: Principles, Techniques, and Tools》，这是一本讲编译原理的书，属于编译原理界的殿堂级存在。另外还有两本经典著做，称号分别是“虎书”、“鲸书”，三者经常一块儿出现。二、IIRC，If I Remember Correctly，若是我没记错。）

我也熟悉 LL(1) 解析器，并已认真地编写过一些递归降低的 LL(1) 解析器——我很喜欢它，并且还熟悉 LL(1) 解析器的生成技术（一样是由于龙书），因此我有了一个改进念头想要试验下：使用正则表达式（某种程度的）而不是标准的 BNF 格式。

龙书还教会了我如何将正则表达式转换成 DFA，因此我把全部这些东西一结合，pgen 就诞生了。【更新：请参阅下文，对于这个理由，有个略微不一样的版本。】

我曾不熟悉更高级的技术，或者曾认为它们效率过低。（在当时，我以为工做在解析器上的大多数人都是这样。）

至于词法分析器（lexer），我决定不使用生成器——我对 Lex 的评价要比 Yacc 低得多，由于在尝试扫描超过 255 个字节的标记符时，我所熟悉的 Lex 版本会发生段错误（真实的！）。此外，我认为缩进格式很难教给词法分析器生成器。

（译注：一、这里的生成器并非 Python 语法中的生成器，而是指用来生成分析器的工具。Lex 是“LEXical compiler”的简称，用来生成词法分析器；Yacc 是“Yet another compiler compiler”的简称，用来生成语法分析器。二、段错误，原文是 segfault，全称是 segmentation fault，指的是由于越界访问内存空间而致使的报错。）

pgen2 的故事则彻底不一样。

我曾受雇于 San Mateo 的一家创业公司（即 Elemental Security，倒闭于 2007，以后我离开并加入了 Google），在那我有一项设计定制语言的任务（目标是做关于系统配置的安全性断定），并拥有至关大的自主权。

我决定设计一些稍微像 Python 的东西，用 Python 来实现，而且决定要重用 pgen，可是后端要基于 Python，使用 tokenize.py 做为词法分析器。因此我用 Python 重写了 pgen 里的那些算法，而后继续构建了剩余的部分。

管理层以为把工具开源是有意义的，所以他们很快就批准了，而在不久以后（我当时极可能已经转移到 Google 了？），这工具对于 2to3 也是有意义的。（由于输入格式跟原始的 pgen 相同，用它来生成一个 Python 解析器很容易——我只需将语法文件喂给工具。:-)

更新：建立 pgen 的缘由，还有更多故事

我不彻底记得为何要这样作了，但我刚刚偷看了https://en.wikipedia.org/wiki/LL_parser#Conflicts，我可能以为这是一种新的（对我而言）不经过添加帮助性的规则而解决冲突的方式。

例如，该网页所称的的左分解（将 A -> X | X Y Z 替换成 A -> X B; B -> Y Z | <empty>），我会重写成 A -> X [Y Z]。

若是我没记错，经过“正则表达式 -> NFA -> DFA”的转换过程，解析引擎（该网页中前面的 syntacticAnalysis 函数）依然能够工做在由这些规则所派生的解析表上；我认为这里须要有不出现空白产物的诉求。（译注：“空白产物”，原文是 empty productions，对应的是前文的 <empty>，指的是没必要要出现 empty。）

我还想起一点，由解析引擎生成的解析树节点可能有不少子节点，例如，对于上面的规则 A -> X [Y Z]，节点 A 可能有 1 个子节点（X）或者 3 个（X Y Z）。代码生成器中就须要有一个简单的检查，来肯定它遇到的是哪种可能的状况。（这已经被证实是一把双刃剑，后来咱们添加了一个由单独的生成器所驱动的“解析树 -> AST”步骤，以简化字节码生成器。）

因此我使用正则表达式的缘由，极可能是为了使语法更易于阅读：在使用了必要的重写以解决冲突以后，我发现语法不是那么可读（此处应插入《Python 之禅》的说法 :-) ，而正则表达式则更符合我对于经典语言的语法的见解（除了起着奇怪名字的帮助规则、[optional] 部分以及 * 号重复的部分）。

正则表达式没有提升 LL(1) 的能力，更没有下降它的能力。固然了，所谓“正则表达式”，我想说的实际上是 EBNF ——我不肯定 “EBNF” 在当时是不是一个被明肯定义了的符号，它可能就指对 BNF 的任意扩展。

假如将 EBNF 转换为 BNF，再去使用它，将会致使尴尬的多解析树节点问题，因此我不认为这会是一种改进。

若是让我重作一遍，我可能会选择一个更强大的解析引擎，多是 LALR(1) 的某个版本（例如 Yacc/Bison）。LALR(1) 的某些地方要比 LL(1) 更给力，也更加有用，例如，关键字参数。

在 LL(1) 中，规则 “arg: [NAME =] expr” 无效，由于 NAME 出如今了表达式的第一组里（FIRST-set），而 LL(1) 算法无法处理这样的写法。

若是我没记错，LALR(1) 则能够处理它。可是，在我写完 pgen 的第一个版本的好些年以后，关键字参数写法才出现，那时候我已不想重作解析器了。

2019 年 3 月更新： Python 3.8 将删除 pgen 的 C 版本，转而使用重写的 pgen2 版本。请参阅 https://github.com/python/cpython/pull/11814

（译注：感受能够帮 Guido 再加一条“更新”了，目前他正在研究 PEG 解析器，将会做为 pgen 的替代。详情请看《Python之父新发文，将替换现有解析器》）

公众号【Python猫】， 本号连载优质的系列文章，有喵星哲学猫系列、Python进阶系列、好书推荐系列、技术写做、优质英文推荐与翻译等等，欢迎关注哦。</empty></empty>