Python 为什么如此设计?
大概两年半前,我萌生了要创作一个新的系列文章的想法,也就是“Python为什么”,试图对 Python 的语法及特性提出“为什么”式的问题,以此加深对它的理解,探寻使用技巧、发展演变、设计哲学等话题。
一直以来,我都是一个有着较强问题意识的充满着好奇心的人,擅长于识别出相似东西的差异,并从差异性上发现事物的独特意义。
于是,当将 Python 与其它编程语言作比较时,加上阅读及翻译了一些 PEP 从而积攒了一些素材后,我就得到了很多的小发现。当确认了国内外的技术社区里缺少这方面的文章后,我就更确信了这件事的独特价值。
我当时有个天真的想法,觉得可以按照“十万个为什么”的方式,写出源源不断的文章……
刚开始的 2020 年下半年,我创作力旺盛,写了约 20 篇“Python 为什么”系列文章!然而,到了 2021 年,仅有 2 篇!再到 2022 年,也是仅仅 2 篇!!……
时间都去哪儿了?怎么我才稍稍微偷了个懒儿,它就不见了呢?本来计划有不少想写的话题的,怎么拖着拖着就忘了该怎么写了呢……
最近眼看到了年末,我越想越是有些不甘,于是,花了几天时间,好好梳理了下“Python 为什么”系列文章,优化了 Github 的介绍内容,准备认真把这个系列重拾起来!
我把之前调查问卷里遗留的问题,以及其它计划要写的话题放在 Issues 跟踪,欢迎大家来提问题/给建议/指导写作/监督催更……
下面放出的是目前系列文章的介绍,恳请喜欢本系列的同学给颗 star 鼓励一下!(内容会不断更新/增长,请以 Github 主页为准。)
如果你在手机微信端阅读,由于链接跳转麻烦,建议你通过这个合集的链接进行阅读。
文章列表
Python 官方提供了约 30 个常见问题的 FAQ,你可以从中快速得到“权威”的解释
介绍了《流畅的 Python》及 Guido 的解释
我本人认为这体现了 Python 对世界本质的洞察
文章顺便回答了:为什么 Python 的索引从 0 开始计数?
这是个经典的问题,总会被提起,我总结了 8 个原因
有不少人对上述 8 个原因并不买账,因此我补充了一个回复:Python 的缩进绝不是反人类的设计!
Guido 在一次采访中说:严格要求代码缩进确实有点夸张,改用花括号,也不是不可以
Python 的缩进起源于 ABC,而 ABC 的缩进起源于 60-70 年代的编程畅想
分号一般有分隔符与终止符两种作用,但 Python 只用分号作为分隔符,却不用它作为终止符, 而是改用换行作为终止符。本文精炼总结了 5 个原因
main 函数作为某些编程语言的执行入口是强制必要的,然而 Python 这门脚本语言有着自己更为灵活的执行方式
在我的编程习惯中,我反感那些不假思索的
if __name__ == '__main__'
写法,文中给出了我的编程建议编程语言中有好几种变量命名风格,最为流行的两种分别是驼峰命名法和蛇形命名法。本文从编程语言的历史发展过程和语言内部的使用习惯角度,解释了为什么 Python 更偏好于蛇形命名法
有过 C/C++/Java 等语言的编程经验的开发者会疑惑,为什么 Python 中没有 i++ 这样的语法
这个问题反映出 Python 中的数字对象跟其它语言中的数字有着根本性的差异;另外,Python 的可迭代对象特性,也深刻影响着语言的诸多设计方面
很多人以为“a,b=b,a”(交换变量操作)跟“a,b=1,2”(多变量赋值)一样,都是基于元组解包的特性,然而 CPython 的实现并非如此
CPython 使用专门的优化指令(即 ROT_TWO、ROT_THREE 和 ROT_FOUR)实现栈顶元素的快捷交换
当同时交换的元素数量大于 4 个时,解释器才会跟“a,b=1,2”(多变量赋值)一样,基于解包实现变量赋值
注释符是编程语言中最基础的要素之一,Python 属于“# 号注释符阵营”,原因或许是它遵循着 Shell 等脚本语言的传统
Python 中不存在“块注释符”,Guido 曾建议使用多行字符串(multi-line strings)来达到块注释的效果,但这种方案在语义上有点怪异
pass 是 Python 独有的一种空操作,其它语言并没有这样的设计
pass 可以作为一种空间占位符,辅助程序员快速编程,然而这点小用途并非至关重要的
由于 Python 不使用花括号之类的手段来划分代码块,因此在定义空函数时,pass 就成了一种补齐语法逻辑的方案
... 是 Python3 在 PEP-3100 中引入的一个内置常量,与 Ellipsis 表示同一个对象
官方说它们是单例的,然而这有违事实。要么是文档错了,要么这是一个 Bug ?
... 有什么用处,能够解决什么问题?文中介绍了 4 个用途:扩展切片语法、表达“未完成的代码”语义、Type Hint 用法、表示无限循环
这也是 Python 与众不同的一个特性,它将其它语言中仅限于布尔类型的操作(if 或 while 或布尔操作 and、or、not),扩展到了任意对象,带来了极大的灵活性
真值判断的结果取决于__bool__() 和 __len__() 这两个魔术方法的返回值
Python 甚至可以对数字对象作真值判断(表示 0 的数为 False,其它数为 True)
Python 隐性地为没有带 return 的函数添加一个 return 操作,即默认返回 None 值,这是由解释器强行注入的逻辑。这意味着:Python 中不存在无返回值的函数
为什么 Python 要强制令所有函数都有一个返回值呢?为什么它不支持无返回值的空函数呢?
void 通常指的是一种类型(type),但是它没有具体的值(value)。文中介绍了其它语言需要使用 void 关键字实现的两种功能
Python 舍弃了表示“没有值的类型”的 void,统一使用表示“仅有一个值的类型” None,配合前一篇“所有函数必然有返回值”的设计,实现了简单好用的效果
动静类型与强弱类型是两组不同维度的概念,不应混为一谈。在编程语言发展的早期,当强弱类型的概念还未提出时,一些大佬使用动静类型来笼统地描述语言的特性,这是历史原因
如今主流观点以“隐式类型转换”来划分强弱类型,Python 毫无疑问是强类型语言。文中针对几个易混淆的问题,详细解释了为什么 Python 中不存在“隐式类型转换”
lambda 语法借鉴自 lisp 语言,却遭到 Python 之父的嫌弃,然而它竟从他的屠刀下幸存,这段故事充满戏剧性
Python 的 lambda 只支持单行表达式,功能不完备。曾有人提议增强 lambda 语法,Python 之父认为那不是好的设计,因而否决了
Guido 提出要一次性移除 reduce()、map()、filter() 以及 lambda,但最后他妥协了
大多数语言都提供了 switch 语句或者极其相似的东西,但在 Python 之父的裁决下,Python 不提供 switch 语句
文章介绍了试图引入 switch 语句的 PEP-275 与 PEP-3103,总结了这两个提案的要点以及被否决的原因
两种创建列表的 [] 与 list() 写法,哪一个更快呢,为什么它会更快呢?
文章通过字节码与执行过程的分析,解释了两者执行速度的差异
内置函数的名称并不是关键字,而内置作用域位于名称查找的最低优先级,因此在调用时,某些内置函数/类型的执行速度就明显慢于它们对应的字面量表示法
由《流畅的 Python》中的例子,引出 Python 在内置类型子类化时不合常理的话题
分析魔术方法的底层实现逻辑及调用关系,解释内置类型存在的问题
介绍了内置类型子类化的最佳实践
Python 是强类型语言,在不经过强制类型转换的情况下,字符串无法拼接数字
介绍了 PEP-498 实现 f-string 的原理
切片是不少编程语言的特性,Python 的切片不仅功能完善,而且在使用上更为灵活
索引越界是一个常见的问题,Python 切片使用了几条规则,屏蔽了可能导致出错的情况
文章介绍了 Python 的解决方案,但是也留下了一个疑问:为什么 Python 的切片语法要允许索引超出边界呢,为什么不设计成抛出索引错误?
有很多内置方法可以生成迭代器,然而似乎只有 range() 生成的是可迭代对象,这个 range() 显得非常独特。文中给出了我对此的猜想
我还注意到 range 是一种不可变序列,然而它跟字符串这种不可变序列相比,也有着独特的表现
这也是一个常见问题。这里给出了官方文档的解释,另外附了 Guido 的一篇博客全文
在 C/C++、C#、PHP、Java、JavaScript 等语言中,do-while 是一种基本结构。Python 为什么不沿袭它们的传统呢?有什么特殊的考虑?
文章列举了其它语言中 do-while 语法的主要使用场景,解释了为什么 Python 可以不用这种结构
介绍了 PEP-315 试图引入 do-while 结构的尝试,以及 Guido 的反对意见
Python3 与 Python2 最显眼的一个区别就是:print 语句变成了 print() 函数
PEP-3105 Make print a function 是对这个问题最好的回答
__missing__() 是仅在内置类型的子类上才存在的魔术方法,似乎是唯一的特例
__missing__() 极为特殊,Python 解释器为它开了后门,实现了最为罕见的“魔术方法间调用”逻辑
elif 写法相比于“else if”更为简洁,这种写法并非 Python 首创。Guido 发推特解释了这种写法的来源
当在两年半前写下第一篇“Python 为什么”系列的时候,我无法想象自己会在 2023 年到来之际写下这一篇宣告重新起航的小结,更无法想象是在下一个两年半,或者五年半或者更久,再次写下一篇新的总结。谁说得准呢!
但是,不忘初心,珍惜当下的决心,树立砥砺前行的恒心,我可以的!
最后,别急着划走啊,请一定记得点个关注、点个 star 哈,喵喵喵~~
版权声明: 本文为 InfoQ 作者【Python猫】的原创文章。
原文链接:【http://xie.infoq.cn/article/d3418df3df365201f5fa4343a】。文章转载请联系作者。
评论