我刚刚发现了一个极好的、简洁的记忆方法:

动态/静态类型表达式;强/弱类型值。

有一些重要的问题，我认为所有现有的答案都忽略了。

弱类型意味着允许访问底层表示。在C语言中，我可以创建一个指向字符的指针，然后告诉编译器我想把它用作指向整数的指针:

char sz[] = "abcdefg";
int *i = (int *)sz;

在一个32位整数的小端序平台上，这使得i成为一个数字0x64636261和0x00676665的数组。事实上，你甚至可以将指针本身转换为整数(大小合适):

intptr_t i = (intptr_t)&sz;

当然，这意味着我可以覆盖系统中任何位置的内存

char *spam = (char *)0x12345678
spam[0] = 0;

*当然，现代操作系统使用虚拟内存和页面保护，所以我只能覆盖我自己的进程内存，但C本身没有提供这样的保护，任何曾经在经典Mac OS或Win16上编码的人都可以告诉你。

传统的Lisp允许类似的黑客行为;在某些平台上，双字浮点和cons单元格是同一类型的，你可以将其中一个传递给一个函数，期待另一个，它就会“工作”。

今天的大多数语言都不像C和Lisp那么弱，但其中许多仍然存在漏洞。例如，任何有未检查的“向下转换”的OO语言*都是类型泄漏:你实际上是在告诉编译器“我知道我没有给你足够的信息来知道这是安全的，但我非常确定它是安全的”，而类型系统的全部意义在于编译器总是有足够的信息来知道什么是安全的。

*被检查的向下转换不会因为将检查移到运行时而使语言的类型系统变得更弱。如果是这样，那么子类型多态性(又名虚拟或全动态函数调用)将同样违反类型系统，我认为没有人愿意这样说。

Very few "scripting" languages are weak in this sense. Even in Perl or Tcl, you can't take a string and just interpret its bytes as an integer.* But it's worth noting that in CPython (and similarly for many other interpreters for many languages), if you're really persistent, you can use ctypes to load up libpython, cast an object's id to a POINTER(Py_Object), and force the type system to leak. Whether this makes the type system weak or not depends on your use cases—if you're trying to implement an in-language restricted execution sandbox to ensure security, you do have to deal with these kinds of escapes…

你可以使用struct这样的函数。unpack来读取字节，并根据“C如何表示这些字节”构建一个新的int，但这显然没有漏洞;甚至Haskell也承认这一点。

与此同时，隐式转换与弱的或有漏洞的类型系统确实是两码事。

Every language, even Haskell, has functions to, say, convert an integer to a string or a float. But some languages will do some of those conversions for you automatically—e.g., in C, if you call a function that wants a float, and you pass it in int, it gets converted for you. This can definitely lead to bugs with, e.g., unexpected overflows, but they're not the same kinds of bugs you get from a weak type system. And C isn't really being any weaker here; you can add an int and a float in Haskell, or even concatenate a float to a string, you just have to do it more explicitly.

And with dynamic languages, this is pretty murky. There's no such thing as "a function that wants a float" in Python or Perl. But there are overloaded functions that do different things with different types, and there's a strong intuitive sense that, e.g., adding a string to something else is "a function that wants a string". In that sense, Perl, Tcl, and JavaScript appear to do a lot of implicit conversions ("a" + 1 gives you "a1"), while Python does a lot fewer ("a" + 1 raises an exception, but 1.0 + 1 does give you 2.0*). It's just hard to put that sense into formal terms—why shouldn't there be a + that takes a string and an int, when there are obviously other functions, like indexing, that do?

*实际上，在现代Python中，这可以用OO子类型来解释，因为isinstance(2, numbers.Real)为真。我不认为在Perl或JavaScript中，2是字符串类型的实例……尽管在Tcl中，它实际上是，因为所有东西都是字符串的实例。

最后，还有另一个完全正交的“强”和“强”的定义。“弱”类型，其中“强”意味着强大/灵活/富有表现力。

For example, Haskell lets you define a type that's a number, a string, a list of this type, or a map from strings to this type, which is a perfectly way to represent anything that can be decoded from JSON. There's no way to define such a type in Java. But at least Java has parametric (generic) types, so you can write a function that takes a List of T and know that the elements are of type T; other languages, like early Java, forced you to use a List of Object and downcast. But at least Java lets you create new types with their own methods; C only lets you create structures. And BCPL didn't even have that. And so on down to assembly, where the only types are different bit lengths.

因此，从这个意义上说，Haskell的类型系统比现代Java的类型系统更强，现代Java的类型系统比早期Java的类型系统更强，早期Java的类型系统比C的类型系统更强，C的类型系统比BCPL的类型系统更强。

So, where does Python fit into that spectrum? That's a bit tricky. In many cases, duck typing allows you to simulate everything you can do in Haskell, and even some things you can't; sure, errors are caught at runtime instead of compile time, but they're still caught. However, there are cases where duck typing isn't sufficient. For example, in Haskell, you can tell that an empty list of ints is a list of ints, so you can decide that reducing + over that list should return 0*; in Python, an empty list is an empty list; there's no type information to help you decide what reducing + over it should do.

*事实上，Haskell不允许你这样做;如果在空列表上调用不接受起始值的reduce函数，则会得到一个错误。但是它的类型系统足够强大，您可以使其工作，而Python的类型系统则不行。

Python变量存储对表示该值的目标对象的无类型引用。

任何赋值操作都意味着将未类型化的引用赋值给已赋值的对象——即对象通过原始引用和新引用(已计数)共享。

值类型绑定到目标对象，而不是引用值。(强)类型检查是在执行带有该值的操作(运行时)时执行的。

换句话说，变量(技术上)没有类型——如果想要精确，那么按照变量类型来考虑是没有意义的。但是引用是自动解除引用的我们实际上是根据目标对象的类型来考虑的。

我刚刚发现了一个极好的、简洁的记忆方法:

动态/静态类型表达式;强/弱类型值。

TLDR;

Python类型是动态的，所以你可以将字符串变量更改为int(在静态语言中你不能)

x = 'somestring'
x = 50

Python类型是强的，所以你不能合并类型:

'foo' + 3 --> TypeError: cannot concatenate 'str' and 'int' objects

在弱类型Javascript中，这种情况会发生……

 'foo'+3 = 'foo3'

关于类型推断

有些语言(如Java)强制显式声明对象类型

int x = 50;

像Kotlin这样的其他人只是从值本身推断它是一个int型

x = 50

但是因为这两种语言都使用静态类型，x不能从int型改变。两种语言都不允许像这样的动态变化

x = 50
x = 'now a string'

现有的答案大多同意Python是一种强类型语言，因为它不会隐式地将值从一种类型转换为另一种类型。这些答案提到了将字符串添加到整数的情况来支持这种说法;"foo" + 3在Python中引发TypeError，而在Javascript(通常被认为是弱类型语言)中，数字3隐式转换为字符串，然后连接，因此结果是字符串"foo3"。

但在其他一些情况下，Python确实会执行隐式类型转换:

# implicit conversion from int to float
1 + 1.0

# implicit conversion from list to bool
if []: pass

相比之下，f#(通常被认为是强类型语言)不允许这两种:

  1 + 1.0;;
  ----^^^
error FS0001: The type 'float' does not match the type 'int'

  if [] then 1 else 2;;
  ---^^
error FS0001: This expression was expected to have type bool but here has type 'a list  

因此，“强类型”和“弱类型”语言并没有严格的二分法，相反，我们可以说Python比Javascript更强类型，但没有f#强类型。