python文档中文_python官方出中文文档了

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

算了，迟早要科普，之前被锑度吃了的凭印象再复述一遍吧。

我为什么要特别集火“堆栈”作为例子？因为不管是这种词语的创造者，连同没有意识到问题的读者在内，都是典型的没文化的体现，某种意义上堪称反智代表——而且特别讽刺的是，其中很大部分是牵涉到母语的理解问题上。

作为理论计算机科学和信息技术类的 stack 的翻译，“堆栈”这个词在信达雅上都是不合格的。

首先，正常一点的翻译是，stack 是“栈”，而“堆”是 heap ；这是和“堆栈”同时期就有的译法。——注意，如果目的是为了清晰表意，“堆”“栈”就该是两个而不是一个概念；分不清楚的，属实应该温习一下怎么数数了。

由于到这两个概念本来在相关领域已经有关联性，却又都是截然不同的(且每个概念在原文中即有还有不同含义但又有历史关联的单独义项的)专业术语，直接简单粗暴的放置很容易导致误会和不懂装懂一错再错以讹传讹。

由于误导的基数庞大，“堆栈”不管是读还是写都不便就词语上看出原本概念的清晰面目。

让清楚的读者搞不清原意，让浑浑噩噩的用户继续稀里糊涂，此所谓不信。

第二，有点母语基础的用户应该能理解到这种翻译的构词方法上的来源——偏义复词，即使用冗余的词素来构词。

这在古汉语中是比较常见的短语构造方法。但是用在现代汉语中构造单一翻译，极为不妥——尤其是用于专业术语，每个词素都是有明确单独概念，容易造成初次接触者误会的情形。

就古汉语的特点来讲，偏义复词中表达实际含义和冗余的词素位置是不确定的，具有临时性，需要按具体实例分析。而按现代汉语的习惯，有生命力的传承习用词语，要么是强调相对性(“得失”“利害”“成败”之类，和本例无关)，否则基本都定型为是首个词素表达词义，如“窗户”“国家”“妻子”“人物”“忘记”“质量”，概莫如是。

然而“堆栈”偏偏反其道而行之，表达实义的“栈”是第二个词素，“堆”却是冗余的。这是有何居心？

有不止一个通顺的选择却偏偏选择最能添乱的，此所谓不达。

第三，就构词方法的选择来看，目的性也非常模糊。

从事实上凭空制造麻烦的构词和词素本身的选择的遣词问题来看，译者的语文素养着实不行，不知是为了显摆什么。

古人使用偏义复词，大体原因无外乎凑足字句协调音韵缓冲语气之类的修辞目的。但是专业术语用得着这些？造区区一个“堆栈”，还打算来写韵文骈文、凑前股后股不成？

不顾目的和场合，不合时宜地卖弄莫须有的风雅，此所谓不雅。

附带对比，全国科学技术名词审定委员会给出的相关领域的翻译[termonline] 中“栈”和“堆栈”都有，但“栈”明确对应 stack 而“堆栈”没有单独的术语，且合成术语中“栈”占绝对多数。

数学中还有把 stack algorithm 翻译成“堆叠存储算法”的，和对岸总是“堆叠”倒是相映成趣。不过好像脑补了些东西……

题外话，把 push 翻译成进栈是有问题的，因为原文的同源词也可以是表示 enqueue 或者 push to dequeue ，和 stack 不一定有直接关系了。

别的嘛……“堆栈式货运索道”——disposal material ropeway；“货垛”——stack of freight 之类显然不是一回事的就算了吧。

拿 stack 来说事的另一方面倒是和翻译没直接关系，而是这词原文的用户本身也有“没文化”的历史遗留问题。顺便也可以带上 heap 。

首先，stack 和 heap 最常用的义项是两种不同的抽象数据结构。稍微具体一点，前者是带 LIFO(last-in-first-out) 约束的线性表，后者是和有序(近似)完全二叉搜索树同构的数据结构。

其次，stack 和 heap 还有不同义项的“重载”。这样的不同义项造成了严重的误导和混乱并且始终无法彻底解决。

历史上，stack 具有的 LIFO 特性被普遍带有使用环境(environment) 来保存状态而实现可调用抽象的替换(substitution) 语义的语言实现机制。

实际上直接实现的这种替换(“调用”)过程的数据结构，是复数的活动记录(activation records) 。使用 stack 是一种经济的实现手段，但不表示不能用其它方式如 hash table 实现。

使用 stack 流行开来的，主要源自 ALGOL60 。这在具体语言里本身不是问题(特别是 ALGOL60 还是 design by commitee 的)，问题是之后很多缺乏对活动记录这个基本概念理解的作者，以讹传讹就把这玩意儿叫 (the) stack 了。

对活动记录的理解和想象力匮乏很大程度上直接影响了控制结构的选择。像 coroutine 之类在 1960 年代就该搞清楚的东西，在半个世纪之后仍然有作者把它当作 distinguishing new feature ，实在好笑。

而更严重的是 ALGOL60 的硬件实现的有效性进一步限制了之后硬件设计者对指令集架构(ISA, instruction set architecture) 选择的偏好——总是提供局部性能看起来更好，却在实现高级控制结构时实在无能的 native stack 。于是要实现有能的语言，就算要用 LIFO 的 stack 也不得不另外单独维护而并没有享受这里的“好处”，甚至有调用约定(calling convention) 上的添乱(如 PowerPC 上的 SML/NJ 实现)。

这个问题严重性之一体现在，到现在所谓主流的 native 语言在这里实质上是无法保证可移植的，例如因为照顾到允许利用 native stack ，ISO C 和 ISO C++ 都不对嵌套函数调用的局部对象存储多大有保证，资源不够用总是未定义行为。如 POSIX 等进一步的规范也并不对这里的检测有提供多少积极的方案，于是应用开发者基本上都假装这个问题不存在。而今天最终用户能“享受”到的 stack overflow 之所以是安全漏洞，很大程度始作俑者也就是这里。

像 MISRA C 之类的“禁用递归”(调用)的鸵鸟政策也不能确保解决这里的安全问题(不递归调用照样能 stack overflow )，反倒是教坏了不少小朋友，加深对递归调用的误解，或者甚至都教育得连一般意义上的递归(如算法的递归描述)和具体语言实现中的递归调用的区别都分不清楚。这种程度的问题教育上都没法扯清，理论界大体装作不知道，如何指望工业界还能在依赖这方面的问题上实际生产出多靠谱的玩意儿？

类似地，heap 本来也是指实现，一般的概念是自由存储(free store) 。据信 1960 年代的 LISP 实现使用 heap 作为自由存储的实现。这个实现被讹传到主流的操作系统的 free store 的分配机制中，逐渐取代了自由存储的存在感。

这个问题虽然看来没有 stack 那么严重，但是其实错位得更厉害。考虑到 stack 源头算是 LIFO 的数据结构，禁用高级控制结构(如 first-class continuation )的设计中，所谓的 the stack 还真能算是 stack 数据结构的特例。

然而现在的所谓 heap 的自由存储基本上和作为数据结构 heap 无关。特别地，要教会一般小朋友从自由存储上分配 stack 是一般王道做法，就更无厘头了。

看，从下到上都甩不掉“没文化”的锅。

再次，Guido van Rossum 在程序语言理论上也挺没文化的，比如搞不清 proper tail recursion 的作用，也对应该怎么设计活动记录兼顾不同需求一头雾水(关于 PTR 的本质问题，参见 [Clinger98]；关于 TCO 不影响 stack inspection 的讨论，参见 [Clements, Felleisen 03] )。上梁尚且如此，Python 背景下的文化自然更对付不了这类没文化后遗症的问题了。

当然，倒不是针对具体的谁，这类例子业内多了去了……还有搞 LISP 的还有分不清 TCO 和 PTR 被 W.D. Clinger 嘲讽过的……[comp.lang.lisp]

References (不放完整 URL 免得被吃)：

[termonline]

termonline.cn

[Clinger 98]

Proper Tail Recursion and Space Efficiency

[Clements, Felleisen 03]

A Tail-Recursive Semantics for Stack Inspections

[comp.lang.lisp]

groups.google.com/d/msg/comp.lang.lisp/AezzhxTliME/2Zsq7HUn_ssJ