0、序言
我在上一篇文章等分析了 为什么 Python 没有 void 类型 的话题，在文章发布后，有读者跟我谈论起了另一个关于类型的问题，但是，我们很快就涌现了重大不合。
我们紧张的不合就在于：Python 到底是不是强类型措辞？ 我认为是，而他认为不是。
他写了一篇很长的文章《谁见告的你们Python是强类型措辞！
站出来，担保不打你！
》，专门重申了他的不雅观点，但可惜错漏百出。
我曾有想法要写写关于 Python 类型的问题，现在借着这个机会，就来系统地梳理一下吧。
（PS：在我写作进行到差不多一半的时候，微信读者群里恰好也谈论到“强弱类型”的话题！
在与大家谈论时，我的一些想法得到了验证，同时我也学到了很多新知识，以是本文的部分内容有群友们的功劳，特此鸣谢！
）
很多读者该当都熟习动态类型 与静态类型 ，但是很多人也会把它们跟强弱类型 混为一谈，以是我们有必要先作一下观点上的澄清。
这两组类型都是针对付编程措辞而言的，但关注的核心问题不同。
对付“动静类型”观点，它的核心问题是“什么时候知道一个变量是哪种类型”？
一样平常而言，在编译期就确定变量类型的是静态类型措辞，在运行期才确定变量类型的则是动态类型措辞。
例如，某些措辞中定义函数“int func(int a){…}”，在编译时就能确定知道它的参数和返回值是 int 类型，所以是静态类型；而范例如 Python，定义函数时写“def func(a):…”，并不知道参数和返回值的类型，只有到运行时调用函数，才终极确定参数和返回值的类型，所以是动态类型
对付“强弱类型”观点，它的核心问题是“不同类型的变量是否许可隐式转化”？
一样平常而言，编译器有很少（合理）隐式类型转化的是强类型措辞，有较多（过分）隐式类型转化的是弱类型措辞。
例如，Javascript 中的 "1000"+1 会得到字符串“10001”，而 "1000"-1 则会得到数字 999，也便是说，编译器根据利用场合，对两种不同类型的工具分别做了隐式的类型转化，但是相似的写法，在强类型措辞中则会报类型出错。（数字与字符串的转化属于过分的转化，下文会再提到一些合理的转化。）
按照以上的定义，有人将常见的编程措辞画了一张分类图：
按强弱类型维度的划分，可以归纳出：
强类型：Java、C#、Python、Ruby、Erlang（再加GO、Rust）……弱类型：C、C++、Javascript、Perl、PHP、VB……2、过去的强弱类型观点动静类型的观点基本上被大家所认可，然而，强弱类型的观点在问答社区、技能论坛和学术谈论上却有很多的争议。此处就不作罗列了。
为什么会有那么多争议呢？
最紧张的缘故原由之一是有人把它与动静类型混用了。
最明显的一个例子便是 Guido van Rossum 在 2003 年参加的一个访谈，它的话题恰好是关于强弱类型的（Strong versus Weak Typing）：
但是，他们评论辩论的明显只是动静类型的差异。
访谈中还引述了 Java 之父 James Gosling 的话，从他的表述中也能看出，他说的“强弱类型”实在也是动静类型的区分。
其余还有一个经典的例子，C 措辞之父 Dennis Ritchie 曾经说 C 措辞是一种“强类型但是弱检讨”的措辞。如果对照成前文的定义，那他实在指的是“静态类型弱类型”。
为什么这些大佬们会有稠浊呢？
实在缘故原由也很大略，那便是在当时还没有明确的动静类型与强弱类型的观点之分！
或者说，那时候的强弱类型指的便是动静类型。
维基百科上给出了 1970 年代对强类型的定义，基本可以还原成前文提到的静态类型：
In 1974, Liskov and Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."[3] In 1977, Jackson wrote, "In a strongly typed language each data area will have a distinct type and each process will state its communication requirements in terms of these types."[4]
前面几位编程措辞之父该当便是持有类似的不雅观念。
不过，大佬们也意识到了当时的“强弱类型”观点并不充分准确，以是 Dennis Ritchie 才会说成“强类型但是弱检讨”，而且在访谈中，Guido 也特殊强调了 Python 不应该被称为弱类型，而该当说是运行时类型（runtime typing） 。
但是在那个早期年代，基本上强弱类型就等同于动静类型，而这样的想法至今仍在影响着很多人。
3、现在的强弱类型观点早期对付编程措辞的分类实在是殽杂了动静与强弱两个维度，但是，它们并不是逐一对应重合的关系，并不敷以表达编程措辞间的差异，因此就须要有更为明确/丰富的定义。
有人提出了“type safety”、“memory safety”等区分维度，也涌现了静态检讨类型和动态检讨类型，与强弱类型存在一定的交集。
直到涌现 2004 年的一篇集大成的学术论文《Type Systems》（出自微软研究院，作者 Luca Cardelli），专门研究编程措辞的不同类型系统：
论文中对付强弱检讨（也即强弱类型）有一个简短的归纳如下：
Strongly checked language: A language where no forbidden errors can occur at run time (depending on the definition of forbidden error).Weakly checked language: A language that is statically checked but provides no clear guarantee of absence of execution errors.其关键则是程序对付 untrapped errors 的检讨强度，在某些实际已出错的地方，弱类型程序并不作捕获处理，例如 C 措辞的一些指针打算和转换，而《C 程序员十诫》的前几个都是弱类型导致的问题。
论文对付这些观点的定义还是比较抽象的，由于未捕获的缺点（untrapped errors）大多是由于隐式类型转换所致，以是又蜕变出了第一节中的定义，以隐式类型转换作为判断标准。
如今将“对隐式类型转换的容忍度”作为强弱类型的分类标准，已经是很多人的共识（虽然不足全面，而且有一些不同的声音）。
例如，维基百科就把隐式类型转换作为弱类型的紧张特点之一：
A weakly typed language has looser typing rules and may produce unpredictable results or may perform implicit type conversion at runtime.
例如，以 Python 为例，社区的主流意见认为它是强类型措辞，而判断的标准也是看隐式类型转换。
例子有很多，比如 Python 官方的 wiki，它专门回答了Why is Python a dynamic language and also a strongly typed language ，给出了 4 个答案，为 Python 的“动态强类型”定性：
再比如，在《流畅的Python》第11章的杂谈中，也专门提到了强弱类型的分类。（它的用语是“很少隐式类型转换”，算是比较严谨的，但是也缺点地把 C++ 归为了强类型。）
4、Python 是不是强类型措辞？关于“Python 是否属于强类型”话题，在主流不雅观点之外，还存在着不少误解的意见。
一方面的缘故原由有些人混用了强弱类型与动静类型，这有历史的缘故原由，前面已经剖析了。
其余还有一个同样主要的缘故原由，即有人把弱类型等同于“完备没有隐式类型转换”了，这种想法并不对。
事实上，强弱类型的观点中包含着部分相对主义的含义，强类型措辞中也可能有隐式类型转换。
比如，Rust 措辞为了实现“内存安全”的设计哲学，设计了很强大的类型系统，但是它里面也有隐式类型转换（自动解引用）。
问题在于：怎么样的隐式类型转换是在合理范围内的？以及，某些表面的隐式类型转换，是否真的是隐式类型转换？
回到 Python 的例子，我们可以剖析几种范例的用法。
比如，"test"3 这种字符串“乘法”运算，虽然是两种类型的操作，但是并不涉及隐式类型转换转化。
比如，x=10; x="test" 先后给一个变量不同类型的赋值，表面上看 x 的类型变革了，用 type(x) 可以判断出不同，但是，Python 中的类型是跟值绑定的（右值绑定），并不是跟变量绑定的。
变量 x 准确地说只是变量名，是绑定到实际变量上的一个标签，它没有类型。type(x) 判断出的并不是 x 本身的类型，而是 x 指向的工具的类型，就像内置函数 id(x) 算出的也不是 x 本身的地址，而是实际的工具的地址。
比如，1 + True 这种数字与布尔类型的加法运算，也没有发生隐式类型转换。由于 Python 中的布尔类型实在是整型的子类，是同一种类型！
（如果有疑问，可查阅 PEP-285）
再比如，整数/布尔值与浮点数相加，在 Python 中也不须要作显式类型转换。但是，它的实现过程实在是用了数字的__add__() 方法，Python 中统统皆工具，数字工具也有自己的方法。（其它措辞可不一定）
也便是说，数字间的算术运算操作，实在是一个函数调用的过程，跟其它措辞中的算术运算有着实质的差异。
其余，不同的数字类型虽然在打算机存储层面有很大差异，但在人类眼中，它们是同一种类型（宽泛地分），以是就算发生了隐式类型转换，在逻辑上也是可以接管的。
末了，还有一个例子，即 Python 在 if/while 之后的真值判断，我之前剖析过它的实现事理 ，它会把其它类型的工具转化成布尔类型的值。
但是，它实际上也只是函数调用的结果（__bool__() 和 __len__()），是通过打算而得出的合理结果，并不属于隐式的逼迫类型转换，不在 untrapped errors 的范畴里。
以是，严格来说，前面 5 个例子中都没有发生类型转换。 浮点数和真值判断的例子，直不雅观上看是发生了类型转换，但它们实在是 Python 的特性，是可控的、符合预期的、并没有对原有类型造成毁坏。
退一步讲，若放宽“隐式类型转换”的含义，认为后两个例子发生了隐式类型转换，但是，它们是通过严谨的函数调用过程实现的，也不会涌现 forbidden errors，以是还是属于强检讨类型。
5、其它干系的问题前文对观点的含义以及 Python 中的表现，作了细致的剖析。接下来，为了逻辑与话题的完全性，我们还须要回答几个小问题：
（1）能否以“隐式类型转换”作为强弱类型的分类依据？
明确的分类定义该当以《Type Systems》为准，它有一套针对不同 error 的分类，强弱类型实在是对付 forbidden errors 的处理分类。隐式类型转换是其明显的特色，但并不是全部，也不是唯一的判断依据。
本文为了方便理解，利用这个紧张特色来划分强弱类型，但是要强调，强类型不是没有隐式类型转换，而是可能有很少且合理的隐式类型转换。
（2）假如有其它阐明器令 Python 支持广泛的隐式类型转换，那 Python 还是强类型措辞么？
措辞的标准规范就像是法律，而阐明器是司法者。如果有缺点的司法阐明，那法律还是那个法律，该当改掉缺点的司法行为；如果是法律本身有问题（造成理解释歧义和抵牾，或者该废弃），那就该当修正法律，担保它的确定性（要么是强类型，要么是弱类型）。
（3）为什么说 Javascript 是弱类型？
由于它的隐式类型转换非常多、非常繁芜、非常过分！
比如，Javascript 中123 + null 结果为 123，123 + {} 结果为字符串“123[object Object]”。
其余，它的双等号“==”除了有基本的比较操作，还可能发生多重的隐式类型转换，例如true==['2'] 判断出的结果为 false，而true==['1'] 的结果是 true，还有[]==![] 和[undefined]==false 的结果都为 true……
（4）C++ 是不是弱类型措辞？
前文提到《流畅的Python》中将 C++ 归为强类型，但实际上它该当被归为弱类型。C++ 的类型转换是个非常繁芜的话题，@樱雨楼 小姐姐曾写过一个系列文章做了系统论述，文章地址：如何占领 C++ 中繁芜的类型转换？ 、详解 C++ 的隐式类型转换与函数重载！
、谁说 C++ 的逼迫类型转换很难懂？
强弱类型观点在网上有比较多的争议，不仅在 Python 是如此，在 C/C++ 之类的措辞愈甚。
其实在学术上，这个观点早已有明确的定义，而且事实上也被很多人所收受接管。
那些反对的声音大多是由于观点混用，由于他们忽略了另一种对措辞进行分类的维度；同时，还有一部分值得把稳的缘故原由，即不能认为强类型即是“完备无隐式类型转换”或“只要没有xxx隐式类型转换”。
本文先容了社区中对 Python 的主流分类，同时对几类疑似隐式类型转换的用法进行了剖析，论证出它是一种强类型措辞。
文章表示了作者一向的刨根问底精神，这是“Python为什么”系列文章的风格，如果你喜好本文，欢迎订阅关注！
[1] 谁见告的你们Python是强类型措辞！
站出来，担保不打你！
: https://blog.csdn.net/nokiaguy/article/details/108218260
[2] Strong versus Weak Typing: https://www.artima.com/intv/strongweak.html
[3] https://en.wikipedia.org/wiki/Strong_and_weak_typing#cite_note-2
[4] https://en.wikipedia.org/wiki/Strong_and_weak_typing#cite_note-3
[5] Type Systems: http://lucacardelli.name/Papers/TypeSystems.pdf
[6] C 程序员十诫: http://doc.cat-v.org/henry_spencer/ten-commandments
[7] Why is Python a dynamic language and also a strongly typed language: https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
[8] PEP-285: https://github.com/chinesehuazhou/peps-cn/blob/master/StandardsTrack/285--%E6%B7%BB%E5%8A%A0%E5%B8%83%E5%B0%94%E7%B1%BB%E5%9E%8B.md
[9] Type Systems: http://lucacardelli.name/Papers/TypeSystems.pdf
[10] Python为什么: https://github.com/chinesehuazhou/python-whydo
