- "语言A具有静态类型检查，因此它是类型安全的" - "语言B具有动态类型检查，因此它不是类型安全的"
可悲的是，事情并不是那么简单。
在现实世界中，
例如，C和C++不是类型安全的，因为您可以通过Type punning破坏类型系统。 此外，C/C++语言规范广泛允许undefined behaviour (UB)而不是明确处理错误，这已成为安全漏洞的源头，例如stack smashing攻击和format string attack。在类型安全的语言中不应该存在这样的漏洞。早期版本的Java存在一个类型错误，涉及其Generics，证明它并非完全类型安全。
到目前为止，对于像Python、Java、C++等编程语言来说，要证明这些语言是完全类型安全的仍然很困难，因为这需要进行数学证明。这些语言非常复杂，并且编译器/解释器经常会出现报告和修复的错误。
[维基百科] 另一方面，许多语言对于人工生成的类型安全证明来说过于庞大，因为它们通常需要检查成千上万种情况。...由于实现中的错误或其他语言编写的链接库中的错误，某些错误可能会在运行时发生；这些错误可能导致特定情况下给定实现的类型不安全。
在学术界
虽然类型安全和类型系统适用于现实世界的编程，但它们的根源和定义来自于学术界 - 因此，在谈论实际使用的真实编程语言时，“什么是”类型安全的正式定义很难确定。学者们喜欢对称建立小型编程语言，这些语言被称为 玩具语言。只有对于这些语言才能够正式地展示它们是类型安全的（并且证明它们的操作在逻辑上是正确的）。
例如，学者们努力证明 Java 是类型安全的，因此他们创建了一个较小的版本称为 Featherweight Java，并在一篇论文中证明它是类型安全的。同样，Christopher Lyon Anderson 的博士论文选取了 JavaScript 的子集，称其为 JS0 并证明了它是类型安全的。
事实上，像 Python、Java、C++ 这样的正式语言并不完全是类型安全的，因为它们太庞大了。一个微小的错误很容易发生，这会破坏类型系统。
总结
- 不，Python 可能不是 完全类型安全的 - 没有人能够证明它是完全类型安全的，这太难了。你更有可能发现语言中的一个微小错误，证明它不是类型安全的。
- 实际上，大多数编程语言 可能不是 完全类型安全的 - 这是由于相同的原因（只有玩具学术语言被证明是）。
- 你真的不应该相信 静态类型的语言 一定是 类型安全的。它们通常比动态类型的语言更加安全，但是说它们是完全类型安全的是错误的，因为没有证据支持这一点。
参考文献: http://www.pl-enthusiast.net/2014/08/05/type-safety/ 和 https://en.wikipedia.org/wiki/Type_system
9
ctypes，Python 就不是类型安全的。 - Daniel在你最疯狂的梦里也不可能。
#!/usr/bin/python
counter = 100 # An integer assignment
miles = 1000.0 # A floating point
name = "John" # A string
print counter
print miles
print name
counter = "Mary had a little lamb"
print counter
python p1.py
100
1000.0
John
Mary had a little lamb
如果一个编程语言可以轻松地将变量的内容从整数转换为字符串，那么无论如何你都不能认为它是“类型安全”的。
在专业软件开发的实际世界中，“类型安全”是指编译器会捕捉到愚蠢的错误。是的，在C/C++中，你可以采取非常规措施来规避类型安全性。你可以声明像这样的内容：
union BAD_UNION
{
long number;
char str[4];
} data;
但是程序员必须付出额外的努力才能做到这一点。我们不需要在Python中走额外的英寸来扭曲计数器变量。
C/C++中的程序员可以通过转换做一些讨厌的事情，但他们必须有意地这样做，而不是无意间。
最容易让你犯错的地方是类转换。当您声明一个带有基类参数的函数/方法，然后传递指向派生类的指针时，您并不总是得到所需的方法和变量，因为方法/函数期望基本类型。如果在您的派生类中覆盖了任何内容，则必须在该方法/函数中加以考虑。
在现实世界中，“类型安全”的语言有助于保护程序员免于无意中做出愚蠢的事情。它还保护人类免受致命伤害。
考虑胰岛素泵或输液泵。它们会将限量的延长生命的化学物质按照所需的速率/间隔注入人体。
现在考虑一下，当存在一个逻辑路径时，泵步进控制逻辑试图将字符串“insulin”解释为要管理的整数量时会发生什么。结果将不会是好的。最有可能是致命的。
您可以通过检查输入的类型来手动强制执行程序中的类型安全。由于所有内容都是对象，因此您始终可以创建从基类派生的类，并使用isinstance函数验证类型（当然是在运行时）。Python 3添加了类型提示，但这并不强制执行。如果您想使用它，mypy已将静态类型检查添加到语言中，但这并不保证类型安全。
6
- 大多数情况下，最后时刻是由客户经历的（在已部署的产品中，出现了特殊情况/问题）。
1
>>> 'a' + 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
由于这种检查只发生在运行时而不是在运行程序之前，因此Python不是一种类型安全的语言（尽管PEP-484除外）。
7
- 天真的答案可能是“编译器是你的朋友”。尽管已经有65年历史了，但这是真实的。嘿，这不仅仅是关于静态类型！IDE（集成开发环境）使用编译器服务来完成许多事情，对于普通程序员来说，这些看起来像魔法...（代码自动补全、设计时间（编辑）辅助等）
- 更现实的原因在于，这对于没有扎实计算机科学和软件工程背景的开发人员来说完全是未知的。可扩展性有三个方面：a. 设计/编写和部署，b. 运行时和c. 维护时间，基于重构。你认为哪一个最昂贵？在任何真实的严肃系统中都会明显地反复出现的是第三个（c）。为了满足（c），你需要做到安全。为了进行任何安全的重构，你需要进行单元测试和覆盖测试（这样你就可以估计你的单元测试套件覆盖的级别）-记住，当某些东西没有自动测试时，它将会在运行时（周期后期，在客户现场等）出现问题-因此，为了拥有一个体面的产品，你需要有体面的单元测试和测试覆盖率。
现在，让我们来谈谈我们的智力挑战函数（sum）。如果sum（a，b）没有指定a和b的类型，则无法进行良好的单元测试。像断言sum（1,1）是2这样的测试是错误的，因为它只涵盖了假定的整数参数。在现实生活中，当a和b是类型雌雄同体时，就没有办法针对函数sum编写真正的单元测试！甚至有些框架假装从上述残缺的测试用例中推导出测试覆盖结果。这是另一个谎言。
这就是我要说的全部内容！感谢您的阅读，我发布这篇文章的唯一原因可能是让您思考这个问题，也许（也许……）有一天会从事软件工程……
一般来说，大规模/复杂系统需要类型检查，首先是在编译时（静态）和运行时（动态）。这不是学术界的问题，而是一个简单、常识性的经验法则，就像“编译器是你的朋友”一样。除了运行时性能影响之外，还有其他重要的影响，如下所示：
可扩展性的三个方面是：
- 构建时间（在时间和预算内设计和制造安全系统的能力）
- 运行时（显而易见）
- 维护时间（以安全的方式维护（修复错误）和扩展现有系统，通常通过重构实现）
唯一安全的重构方法是对所有内容进行充分测试（使用测试驱动开发或至少单元测试和至少良好的覆盖率测试，这不是质量保证，而是开发/研发）。未覆盖的部分将会出错，这样的系统更像垃圾而不是工程艺术品。
现在假设我们有一个简单的函数sum，返回两个数字的和。可以想象对这个函数进行单元测试，基于已知的参数和返回类型。我们不是在谈论函数模板，它们归结为简单的例子。请编写一个简单的单元测试，测试同样名为sum的函数，其中参数和返回类型可以是任何类型，包括整数、浮点数、字符串和/或任何其他用户定义类型，只要这些类型重载/实现了加号运算符即可。你如何编写这样一个简单的测试用例？！？为了涵盖每种可能的情况，测试用例需要多复杂？复杂性意味着成本。没有适当的单元测试和测试覆盖率，没有安全的方法进行任何重构，因此产品会变得难以维护，虽然这不会立即显现，但长期来看会很明显，因为在盲目进行任何重构就像酒后驾车且没有保险一样危险。
自己琢磨吧！ :-)
if sys.errno:
my_favorite_files.append(sys.errno)
应该使用这个：
if args.errno:
my_favorite_files.append(sys.errno)
将任何东西强制转换为布尔值，因为它使if语句更容易的做法是我不希望在一种类型安全的语言中找到的。
原文链接
'1' + 2。例如，Javascript 就不是类型安全的。 - Eric Duminil