总体上，开发者们希望引入某种形式的 if-then-else 表达式，但投票后却没有哪种方案能取得绝对的优势。概括起来，分歧的问题主要有：是否用标点符号、是否复用关键字、是否复用圆括号、是否引入新关键字、是否引入新语法……
由于得票太分散，因此，这个 PEP 在当时被拒绝了。PEP 中写道：“Python 的一个设计原则是在不确定采取哪条路线时，则保持现状。” and-or 用于条件选择的问题
以上的投票事件发生在 2004 年 3 月，但是，在 PEP 被拒绝后，相关话题的讨论并未平息，因为大家总想找一种简洁的方式来替换“if-else“。
时间到了 2005 年 9 月，邮件组中有人提议在 Py3.0 中变更"and"与"or"操作符的逻辑，提议将"and" 和 "or" 运算符简化成始终返回布尔值，而不是返回最后一个被求值的参数。
之所以发起这个提议，原因是他使用了<condition> and <expression1> or <expression2>的方式来实现条件判断与选择。但是这种写法在 Python 中的行为跟有些语言并不一样，使用不严谨的话，可能会酿成 Bug！
看看下面的两个例子，你觉得它们会得到什么结果呢？
a = True and True or "Python猫"
b = True and False or "Python猫"
对于<condition> and <expression1> or <expression2> ，若 condition 为假，则会直接对 expression2 求值并返回结果；若 condition 为真，则先对 expression1 求值，若也为真，则不会继续对 expression2 求值，若 expression1 不为真，则对 expression2 求值。
因此，上述例子得到的 a 是“True”，而 b 会得到“Python猫”。
本系列的《Python 为什么能支持任意的真值判断？ 》介绍过 Python 在真值判断的特殊之处，运用到以上结构中，将出现更不易察觉的问题。比如，该邮件的作者就是遇到了“expression1”为复数“0+4i”，这个数的真值判断为 False，因此导致最后返回的不是预期的“expression1”，而是“expression2”！
在没有更好的方案前，“and-or”是比较常见的条件选择写法，PEP-308 也提及了它，也指出了当“expression1”为假的情况，还认为这种方案是丑陋和令人费解的。
这封邮件再次引发了社区对条件选择语法的讨论，大佬们纷纷登场。
以我现在的视角分析，其实就是开发者们不满足于“if-else”的现状，但是当时流行的“and-or”写法并不够好，因此，大家期望 Python 设计出新的规范性语法，来解决这个痛点。 与众不同的条件表达式
在经过 10 天的邮件讨论后，Guido van Rossum 最终决定添加一个条件表达式，语法形式为X if C else Y 。因此，PEP-308 被重开和更新，并很快就在次年的 2.5 版本中实现了。
前文已提到过这个让一些人感觉不舒服的方案了，因为它没有将条件判断逻辑放在最前面。
那么，为什么最后的胜者会是它呢？这是不是最优的设计呢？
不可否认，起到决定性作用的原因是 Guido。由于社区在一年半前投票时没有形成多数意见，因此他行使 BDFL （终身仁慈独裁者）的决策权力，裁定出一个他认为是最佳的方案。
X if C else Y 非常易于理解，可读性高。它延续了“明确优于隐式”的风格，使用了直观口语化的“if-else”，而不是引入可能引起混淆的标点符号，就像 Python 选择“and”和“or”两个单词，而不是“&&”和“||”两个符号，它们有着异曲同工之妙。
虽然调整后的语法顺序让人不太习惯，但其实这样的实现却大有好处。首先，它只需复用“if-else”两个关键字，而不需要引入“then”、“when”和其它语法要素，也不像(if <condition>: <expression1> else: <expression2>) 那样的繁琐。
其次，为了验证X if C else Y 的有效性，Guido 排查了标准库中所有“and-or”组合的写法，发现那些C and X or Y 写法都可以被X if C else Y 替换掉。标准库的情况，证明了这新的语法是可行的。
最后，在 PEP-308 提及的原因外，我还想补充一点。据观察，我发现很多时候我们有一个已初始化的变量，然后需要在出现某个条件时，更新变量的值。在这种情况下，“else”部分可以被省略，非常便捷。
my_str = ""
# 中间存在其它代码逻辑
# 当 condition 为真时，变量会被重新赋值
my_str = "Python猫" if condition
回顾这段历史，我们可以梳理出一条线索：Python 没有设计三元运算符“?:”，主要是因为它不符合 Python 明确直观的设计风格。最后采用X if C else Y 这种设计，主要的意图其实是消除“and-or”写法的隐患，这种设计简明易读，而且还有<expression> if <condition> 简化写法的妙用。
总体而言，Python 设计者非常看重可读性与可维护性，不采用三元运算符而创造条件表达式语法，这是一个经过了开放讨论、谨慎评估与权衡取舍的结果。 Go、Rust 为什么不支持三元运算符？
考察完 Python 的设计原因后，我们再来考察“反派阵营”中两门最热门的语言。
首先是 Go 语言，官网的 FAQ 专门列出了一个问题：“Why does Go not have the ?: operator?”。
Go 语言不支持“?:”运算符，而是推荐使用原生的“if-else”写法。文档的解释很简短，只有一段话：
Go 语言没有 ?: 运算符，因为语言的设计者们经常看到它被用来创建难以理解的复杂表达式。虽然 if-else 形式比较长，但是它无疑更清晰易懂。一个语言只需要一个条件控制流结构。
接着是 Rust 语言，它的官方文档中似乎没有任何关于不支持三元运算符的解释。但在查阅资料后，我发现它也有一段特殊的故事，非常有意思：在 2011 年 6 月时，Rust 曾经引入过三元运算符（#565），然而半年后，设计者意识到这个特性是多余的，因此又把它移除了（#1698、#4632）!
为什么三元运算符在 Rust 是多余的呢？因为它的 if 语法并不像其它语言是“语句（statement）”，而是一个“表达式（expression）”，这意味着你可以直接将 if 表达式赋值给变量：
// 若条件为真，得到 5，否则 6
let number = if condition { 5 } else { 6 };
这种语法形式足够简单明了，不就是将大家都熟悉的“if-else”直接用于赋值么，太方便了，替换成三元运算符的话，确实有点画蛇添足之感。
另外，Rust 使用花括号划分代码块，因此上例的花括号内可以包含多条表达式，也支持换行，例如这个例子：
let x = 42;
let result = if x > 50 {
println!("x is greater than 50");
x * 2 // 这是一个表达式，将返回的值赋给 result
} else {
println!("x is less than or equal to 50");
x / 2 // 也是一个表达式，将返回的值赋给 result
};
这种用法，Python 是不可能做到的。最关键的区别在于，Rust 的 if 是表达式而不是语句。
这两个概念的区别是： ·表达式（expression）通常指的是由变量、常量、运算符等组成的一个可求值的代码片段，它的求值结果可以用到其它表达式或语句中。 · 语句（statement）通常指的是完成某个任务的单个指令或一组指令，例如赋值语句、条件语句、循环语句等，它没有返回值（或者为空），不能用于赋值操作。
除了 Rust 外，还有一些编程语言中的 if 是表达式而不是语句，例如 Kotlin、Scala、F#、Swift，它们在理论上也不需要使用三元运算符。（题外话：Swift 是个例外，它也有三元运算符。Kotlin 有“?:”运算符，注意两个符号是连在一起的，val result = a ?: b 表示：如果 a 不为 null，则赋值给 result ；否则将 b 赋给 result）
由于有这种语言设计层面的区别，因此在面对“是否要支持三元运算符”这个问题时，Rust 和 Python/Go 的思考角度有着天然不同的起点。知道了这种区别后，我们对编程语言会有更明晰地认知。
回到本文的问题：为什么有些编程语言不采用主流的三元运算符语法呢？
不可否认，“?:”确实是一种简洁好用的设计，然而，标点符号的负面影响是过于抽象，可读性并不及“if-else”那样强。另外，不同语言的设计风格与使用习惯，也会导致不同的选择。
Python 在经过一番波折后，最后设计出了与众不同的条件表达式。Go 语言明确表示不支持三元运算符。Rust 先设计后舍去，主要的原因在于 if 表达式的语言基础。
考察完这三个热门语言后，我相信你已收获了一个满意的答案。如果是这样，请点赞支持一下本文吧！
