企业官网建设流程全解析

本文的作者是Ned, 他身为一名资深工程师, 当下在在线教育网站Edx就职。文中蓝色下划线的部分, 是能够在“阅读原文”之后去点击操作的。

某种紧凑语法, 能借助一个循环, 以及条件, 去构建一个列表, 如此一种语法, 被称作列表推导式（list）:

=

f(x) for x in if cond(x)

与此相类似, 我们能够借助字典推导式（）来构建字典, 依靠集合推导式（set）建构创建集合。

={函数k(x):对应v(x)针对x在假如满足条件cond(x)的假设范围里}。

等于, 对于在其中的x, 那些满足条件cond(x)的f(x)所构成的集合。

（这一语法支持更加复杂的操作，但这里仅作示例）

最后，你还可以使用类似的语法创建一个生成器：

那是等于, 对于在某个集合里的x, 当满足条件cond(x)时取f(x)形成的式子。

不过, 这并非称作生成器推导式, 而是称作生成器表达式（）。为何不叫前者? 倘若前三个语法皆被叫做“推导式”, 那么生成器这个为何不叫?

PEP 289 , 也就是生成器表达式, 其最后给出了详细备注, 详细备注之中指出, 起初有人提议使用“生成器推导式（）”这个词, 后来 Peter 提出了“累计显示（）”, 至于后来 Tim推荐了“生成器表达式”这一名词, 可它并没有名词出现了如此这般的变化。

：上面提到的这几位都是大牛啊！具体大家可以谷歌一下。

所以我在上提出了这个问题：

存在一个我不理解的问题, 为何它们被称作“生成器表达式”, 而非“生成器推导式”呀?

Guido的回答指出了核心原因：

推导式最初是归属于“字面量显示（）”这个概念范畴的, 然而生成器表达式并非是一种显示（）。

马特·博姆后来寻得了蒂姆, 提出了“生成器表达式”一词的邮件, 于此邮件当中讲述了一些细节。

读完邮件之后, 我对于这个问题的理解变得更深了。首先, 为何会使用“推导式”这个词呢? Tim在邮件里指出, 该词源自集合论中的推导公理, 它所指的是, 经由对另一个集合的元素运用某个谓词, 也就是条件, 进而组成新的集合。这跟向另一个序列里的元素应用某个条件进而生成列表的做法极为相似。

以往, 我瞅见好多被译为“解析”的情况, 直至瞧见此处, 才发觉“推导式”才是更为精准的表述。

Guido所指出的部分, 有着这样的情况, 其设计者当时更为注重的是显示, 并非条件。这里的 “显示” 一词有着特定含义, 意味着代码的语法看上去和它将要创建的数据结构十分相像。列表显示也就是列表推导式, 看上去如同一个列表。集合和字典显示同样也是如此状态, 有着如列表一样的类似情况。然而由于缺少生成器字面量语法, 所以结果是根本不存在一个能用来对比的生成器显示, 进而也就不存在生成器显示了。

设计该功能的那封邮件里, 有一种情况是, “推导式”这个词, 它在特定语境下, 作为“显示”的同义词存在, 然而, 因为生成器不存在显示这种情况, 所以, 也就不可能存在被当作那种意义上同义词的“推导式”了。

不过, Time于他的邮件里也讲了, 推导式非常奇妙的地方在于条件, 推导公理最为关键的部分是谓语, 或许是鉴于推导式当中的条件是可以选择的, 所以关注的重点被转移到了显示这儿。

然而我觉得, 我们理应称它们为“生成器推导式”。我们于描述这类语法之际, 并未运用“显示”这个词汇。 我们不存在把“推导式”跟“显示”以及字面量语法关联起来的缘由。

列表推导式、字典推导式、集合推导式、生成器表达式, 这四个表达式, 各自之间存在着诸多相似之处, 若把四者之间的类似点归结起来并称作“推导式”, 如此便能极大地简化相关概念, 它们之间的相似之处远远多于不同的地方, 我提议大家针对这四个表达式运用相同的概念。

建议：统称为“推导式”。