2004 Django
2008 python3诞生
python2 :源码不统一，源码重复
python3：源码统一，不重复
吉多·范罗苏姆
python的作者，Guido von Rossum，确实是荷兰人。1982年，Guido从阿姆斯特丹大学(University of Amsterdam)获得了数学和计算机硕士学位。然而，尽管他算得上是一位数学家，但他更加享受计算机带来的乐趣。用他的话说，尽管拥有数学和计算机双料资质，他总趋向于做计算机相关的工作，并热衷于做任何和编程相关的活儿。
1989年，为了打发圣诞节假期，Guido开始写Python语言的编译/解释器。Python来自Guido所挚爱的电视剧Monty Python‘s Flying Circus (BBC1960-1970年代播放的室内情景幽默剧，以当时的英国生活为素材)。他希望这个新的叫做Python的语言，能实现他的理念(一种C和shell之间，功能全面，易学易用，可拓展的语言)。Guido作为一个语言设计爱好者，已经有过设计语言的(不很成功)的尝试。这一次，也不过是一次纯粹的hacking行为。
1991年，第一个Python编译器(同时也是解释器)诞生。它是用C语言实现的，并能够调用C库(.so文件)。从一出生，Python已经具有了：类(class)，函数(function)，异常处理(exception)，包括表(list)和词典(dictionary)在内的核心数据类型，以及模块(module)为基础的拓展系统。
最初的Python logo: 由Guido的兄弟Just von Rossum设计
ython语法很多来自C，但又受到ABC语言的强烈影响。来自ABC语言的一些规定直到今天还富有争议，比如强制缩进。但这些语法规定让Python容易读。另一方面，Python聪明的选择服从一些惯例(特别是C语言的惯例)。比如使用等号赋值，使用def来定义函数。Guido认为，如果“常识”上确立的东西，没有必要过度纠结。
Python从一开始就特别在意可拓展性(extensibility)。Python可以在多个层次上拓展。从高层上，你可以引入.py文件。在底层，你可以引用C语言的库。Python程序员可以快速的使用Python写.py文件作为拓展模块。但当性能是考虑的重要因素时，Python程序员可以深入底层，写C程序，编译为.so文件引入到Python中使用。Python就好像是使用钢构建房一样，先规定好大的框架。而程序员可以在此框架下相当自由的拓展或更改。
最初的Python完全由Guido本人开发。Python得到Guido同事的欢迎。他们迅速的反馈使用意见，并参与到Python的改进。Guido和一些同事构成Python的核心团队。他们将自己大部分的业余时间用于hack Python (也包括工作时间，因为他们将Python用于工作)。随后，Python拓展到CWI之外。Python将许多机器层面上的细节隐藏，交给编译器处理，并凸显出逻辑层面的编程思考。Python程序员可以花更多的时间用于思考程序的逻辑，而不是具体的实现细节 (Guido有一件T恤，写着：人生苦短，我用Python)。这一特征吸引了广大的程序员。Python开始流行。
python的发展 硬件性能不是瓶颈，Python又容易使用，所以许多人开始转向Python。Guido维护了一个maillist，Python用户就通过邮件进行交流。Python用户来自许多领域，有不同的背景，对Python也有不同的需求。Python相当的开放，又容易拓展，所以当用户不满足于现有功能，很容易对Python进行拓展或改造(可以理解为学习python的原因)。随后，这些用户将改动发给Guido，并由Guido决定是否将新的特征加入到Python或者标准库中。如果代码能被纳入Python自身或者标准库，这将极大的荣誉。Python自身也因此变得更好。
(Guido不得不作出许多决定，这也是他被称为Benevolent Dictator For Life的原因 （仁慈的独裁者）)
Python被称为“Battery Included”，是说它以及其标准库的功能强大。这些是整个社区的贡献。Python的开发者来自不同领域，他们将不同领域的优点带给Python。比如Python标准库中的正则表达(regular expression)是参考Perl，而lambda, map, filter, reduce函数参考Lisp。Python本身的一些功能以及大部分的标准库来自于社区。Python的社区不断扩大，进而拥有了自己的newsgroup，网站(python.org)，以及基金 (Python Software Foundation)。从Python 2.0开始，Python也从maillist的开发方式，转为完全开源的开发方式。社区气氛已经形成，工作被整个社区分担，Python也获得了更加高速的发展。
(由于Guido享有绝对的仲裁权，所以在Python早期maillist的开发时代，不少爱好者相当担心Guido的生命。他们甚至作出假设：如果Guido挂了的话，Python会怎样。见If Guido was hit by a bus)
到今天，Python的框架已经确立。Python语言以对象为核心组织代码(Everything is object)，支持多种编程范式(multi-paradigm)，采用动态类型(dynamic typing)，自动进行内存回收(garbage collection)。Python支持解释运行(interpret)，并能调用C库进行拓展。Python有强大的标准库 (battery included)。由于标准库的体系已经稳定，所以Python的生态系统开始拓展到第三方包。这些包，如Django, web.py, wxpython, numpy, matplotlib,PIL，将Python升级成了物种丰富的热带雨林。
今天Python已经进入到3.0的时代。由于Python 3.0向后不兼容，所以从2.0到3.0的过渡并不容易。另一方面，Python的性能依然值得改进，Python的运算性能低于C++和Java(见Google的讨论)。Python依然是一个在发展中的语言。我期待看到Python的未来。
Python从其他语言中学到了很多，无论是已经进入历史的ABC，还是依然在使用的C和Perl，以及许多没有列出的其他语言。可以说，Python的成功代表了它所有借鉴的语言的成功。同样，Ruby借鉴了Python，它的成功也代表了Python某些方面的成功。每个语言都是混合体，都有它优秀的地方，但也有各种各样的缺陷。同时，一个语言“好与不好”的评判，往往受制于平台、硬件、时代等等外部原因。程序员经历过许多语言之争。我想，为什么不以开放的心态和客观的分析，去区分一下每个语言的具体优点缺点，去区分内部和外部的因素。
引自：博客园
一行代码实现人工智能
print (input("我是智能机器人，请输入和我聊天的内容").strip("吗？"))
首先做个总结 ： Python是一门动态解释型的强类型定义语言
了解编译型和解释型、静态语言和动态语言、强类型定义语言和弱类型定义语言这6个概念就可知晓。
编译型和解释型
编译型，其实它和汇编语言是一样的，也是有一个负责翻译的程序来对我们的源代码进行转换，生成相对应的可执行代码。这个过程说的专业一点，就称为编译(Compile)，而负责编译的程序自然就称为编译器(Compiler)。如果我们写的程序代码都包含在一个源文件中，那么通常编译之后就会直接生成一个可执行文件，我们就可以直接运行了。但对于一个比较复杂的项目，为了方便管理，我们通常把代码分散在各个源文件中，作为不同的模块来组织。这时编译各个文件时就会生成目标文件(Object file)而不是前面说的可执行文件。一般一个源文件的编译都会对应一个目标文件。这些目标文件里的内容基本上已经是可执行代码了，但由于只是整个项目的一部分，所以我们还不能直接运行。待所有源文件的编译都大功告成，我们就可以最后把这些半成品的目标文件“打包”成一个可执行文件了，这个工作由另一个程序负责完成，由于此过程好像是把包含可执行代码的目标文件连接装配起来，所以又称为链接(Link)，而负责链接的程序就叫链接程序(Linker)。链接程序除了链接目标文件外，可能还有各种资源，像图标文件、声音文件什么的，还要负责去除目标文件之间的冗余重复代码，等等，所以...也是挺累的。链接完成后，一般就可以得到我们想要的可执行文件了。
解释型，现在再看看解释型。从字面上看，“编译”和“解释”的确有“翻译”的意思，他们的区别在于翻译的时机安排不大一样。打个比方：假如你打算阅读一本外文书，而你不知道这门外语，那么你可以找一名翻译，给他足够的时间让他把整本书从头到尾翻译好，然后把书的母语版交给你阅读；或者，你也立刻让这名翻译辅助你阅读，让他一句一句给你翻译，如果你想往回看某个章节，他也得重新给你翻译。
两种方式，前者相当于我们说的编译型：一次把所有代码朱焕为机器语言，然后写可执行文件；而后这就相当于我们说的解释型：在程序运行的前一刻，还只有源程序没有可执行程序；而程序每执行到源程序的某一条指令，则会有有一个称为解释程序的外壳程序将源代码转换成二进制代码以供执行，总言之就是不断的解释、执行、解释、执行.....所以解释型程序是离不开解释程序的。像早期的BASIC就是一门经典的解释型语言，要执行BASIC。解释型程序中由于程序总是以源代码的形式出现，因此只要有相应的解释器，移植几乎不成问题。编译型程序虽然源代码也可以移植，但前提是必须针对不同的系统分别进行编译，对于复杂的工程来说，的确是意见不小时间的消耗，况且很可能一些细节的地方还要需要修改源代码。而且，解释型程序省却了编译的步骤，修改调试也非常方便，编辑完毕之后即可立即执行，不必像编译程序一样每次进行小小改动都要耐心等待漫长Compiling...Linking...这样的编译链接过程。不过凡事有利有弊，由于解释型程序是将编译的过程放到执行过程中，这就决定了解释型程序注定要比编译型慢上一大截，像几百倍的速度差距也是不足为奇的。
编译型和解释型各有利弊。前者由于程序执行速度快，同等条件下对系统要求较低，因此像开发操作系统、大型应用程序、数据库系统时都采用它，像C/C++、Pascal/Object Pascal(Delphi)、VB等基本都可视编译语言，而一些网页脚本、服务器脚本及辅助开发接口这样的对速度要求不高、对不同系统平台间的兼容性有一定要求的程序则通常使用解释型语言，如Java、JavaScript、VBScript、Perl、Python等等。
但既然编译型和解释型各有优缺点又互相对应，所以一批新兴的语言都有把两者折中起来的趋势，例如Java语言虽然比较接近解释型语言的特征，但执行之前已经预先进行一次预编译，生成的代码是介于机器码和Java源代码之间的中介代码，运行的时候则由JVM(Java的虚拟机平台，可视为解释器)解释执行。它既保留源代码的高抽象、可移植的特点，又已经完成了对源代码的大部分预编译工作，所以执行起来比“纯解释型”程序要快许多。而像VB6(或者以前版本)、C#这样的语言，虽然表面上看生成的是.exe可执行程序文件，单VB6编译之后实际生成的也是一种中介码，只不过编译器在前面安插了一段自动调用某个外部解释器的代码(该解释程序独立于用户编写的程序，存放于系统的某个DLL文件中，所有以VB6编译生成的可执行程序都要用到它)，以解释执行实际的程序体。C#(以及其他.net的语言编译器)则是生成.net目标代码，实际执行时则由.net解释系统(就像JVM一样，也是一个虚拟平台)进行执行。当然.net目标代码已经相当低级，比较接近机器语言了，所以仍将其视为编译语言，，而且其移植程度也没有Java号称的这么强大，Java号称是“一次编译，到处执行”，而.net则是“一次编码，到处编译”。总而言之，随着设计技术与硬件不断发展，编译型与解释型两种方式的界限正在不断变得模糊。
动态语言和静态语言
通常我们说的动态语言和静态语言是指动态类型语言和静态类型语言。
动态类型语言，动态类型语言是指在运行期间才去做数据类型检查的语言，也就是说，在用动态类型 语言编译的时，永远也不用给任何变量指定数据类型，该语言会在你第一次赋值给变量时，在内部将数据类型记录下来。Python和Ruby就是一种典型的动态类型语言，其他的各种脚本语言如VBScript也多少属于动态类型语言。
静态类型语言，静态类型语言和动态类型语言正好相反，它的数据类型是在编译期间检查的，也就是说在写程序时要声明所有变量的数据类型，C/C++是静态类型语言的典型代表，其他的静态类型语言还有C#、Java等。
强类型定义语言和弱类型定义语言
强类型定义语言，强制数据类型定义的语言。也就是说，一旦一个变量被指定了某个数据类型，如果不经过强制转换，那么它就永远是这个数据类型了。举个例子，如果您定义了一个整型变量a，那么程序根本不能将a当做字符串类型处理。强类型定义语言是类型安全的语言。
弱类型定义语言，：数据类型可以被忽略的语言。它与强类型定义语言相反。一个变量可以赋不同数据类型的值。
强类型定义语言在速度上可能略逊色于弱类型定义语言，但是强类型定义语言带来的严谨性能够有效的避免许多错误。另外，“这门语言是不是动态语言”与“这门语言是否类型安全”之间是完全没有联系的！
例如：Python是动态语言，是强类型定义语言(类型安全的语言)；VBScript是动态语言，是弱类型定义语言(类型不安全的语言)；Java是静态语言，是强类型定义语言(类型安全的语言)。
引自： 博客园
· Cpython
Python的官方版本，使用C语言实现，使用最为广泛，CPython实现会将源文件（py文件）转换成字节码文件（pyc文件），然后运行在Python虚拟机上。
· Jyhton
Python的Java实现，Jython会将Python代码动态编译成Java字节码，然后在JVM上运行。
· IronPython
Python的C#实现，IronPython将Python代码编译成C#字节码，然后在CLR上运行。（与Jython类似）
· PyPy（特殊）
Python实现的Python，将Python的字节码字节码再编译成机器码。
· RubyPython、Brython ...
[对到顶部](https://i.cnblogs.com/EditPosts.aspx?postid=11636499&update=1)
---恢复内容结束---
2004 Django
2008 python3诞生
python2 :源码不统一，源码重复
python3：源码统一，不重复
吉多·范罗苏姆
python的作者，Guido von Rossum，确实是荷兰人。1982年，Guido从阿姆斯特丹大学(University of Amsterdam)获得了数学和计算机硕士学位。然而，尽管他算得上是一位数学家，但他更加享受计算机带来的乐趣。用他的话说，尽管拥有数学和计算机双料资质，他总趋向于做计算机相关的工作，并热衷于做任何和编程相关的活儿。
1989年，为了打发圣诞节假期，Guido开始写Python语言的编译/解释器。Python来自Guido所挚爱的电视剧Monty Python‘s Flying Circus (BBC1960-1970年代播放的室内情景幽默剧，以当时的英国生活为素材)。他希望这个新的叫做Python的语言，能实现他的理念(一种C和shell之间，功能全面，易学易用，可拓展的语言)。Guido作为一个语言设计爱好者，已经有过设计语言的(不很成功)的尝试。这一次，也不过是一次纯粹的hacking行为。
1991年，第一个Python编译器(同时也是解释器)诞生。它是用C语言实现的，并能够调用C库(.so文件)。从一出生，Python已经具有了：类(class)，函数(function)，异常处理(exception)，包括表(list)和词典(dictionary)在内的核心数据类型，以及模块(module)为基础的拓展系统。
最初的Python logo: 由Guido的兄弟Just von Rossum设计
ython语法很多来自C，但又受到ABC语言的强烈影响。来自ABC语言的一些规定直到今天还富有争议，比如强制缩进。但这些语法规定让Python容易读。另一方面，Python聪明的选择服从一些惯例(特别是C语言的惯例)。比如使用等号赋值，使用def来定义函数。Guido认为，如果“常识”上确立的东西，没有必要过度纠结。
Python从一开始就特别在意可拓展性(extensibility)。Python可以在多个层次上拓展。从高层上，你可以引入.py文件。在底层，你可以引用C语言的库。Python程序员可以快速的使用Python写.py文件作为拓展模块。但当性能是考虑的重要因素时，Python程序员可以深入底层，写C程序，编译为.so文件引入到Python中使用。Python就好像是使用钢构建房一样，先规定好大的框架。而程序员可以在此框架下相当自由的拓展或更改。
最初的Python完全由Guido本人开发。Python得到Guido同事的欢迎。他们迅速的反馈使用意见，并参与到Python的改进。Guido和一些同事构成Python的核心团队。他们将自己大部分的业余时间用于hack Python (也包括工作时间，因为他们将Python用于工作)。随后，Python拓展到CWI之外。Python将许多机器层面上的细节隐藏，交给编译器处理，并凸显出逻辑层面的编程思考。Python程序员可以花更多的时间用于思考程序的逻辑，而不是具体的实现细节 (Guido有一件T恤，写着：人生苦短，我用Python)。这一特征吸引了广大的程序员。Python开始流行。
python的发展 硬件性能不是瓶颈，Python又容易使用，所以许多人开始转向Python。Guido维护了一个maillist，Python用户就通过邮件进行交流。Python用户来自许多领域，有不同的背景，对Python也有不同的需求。Python相当的开放，又容易拓展，所以当用户不满足于现有功能，很容易对Python进行拓展或改造(可以理解为学习python的原因)。随后，这些用户将改动发给Guido，并由Guido决定是否将新的特征加入到Python或者标准库中。如果代码能被纳入Python自身或者标准库，这将极大的荣誉。Python自身也因此变得更好。
(Guido不得不作出许多决定，这也是他被称为Benevolent Dictator For Life的原因 （仁慈的独裁者）)
Python被称为“Battery Included”，是说它以及其标准库的功能强大。这些是整个社区的贡献。Python的开发者来自不同领域，他们将不同领域的优点带给Python。比如Python标准库中的正则表达(regular expression)是参考Perl，而lambda, map, filter, reduce函数参考Lisp。Python本身的一些功能以及大部分的标准库来自于社区。Python的社区不断扩大，进而拥有了自己的newsgroup，网站(python.org)，以及基金 (Python Software Foundation)。从Python 2.0开始，Python也从maillist的开发方式，转为完全开源的开发方式。社区气氛已经形成，工作被整个社区分担，Python也获得了更加高速的发展。
(由于Guido享有绝对的仲裁权，所以在Python早期maillist的开发时代，不少爱好者相当担心Guido的生命。他们甚至作出假设：如果Guido挂了的话，Python会怎样。见If Guido was hit by a bus)
到今天，Python的框架已经确立。Python语言以对象为核心组织代码(Everything is object)，支持多种编程范式(multi-paradigm)，采用动态类型(dynamic typing)，自动进行内存回收(garbage collection)。Python支持解释运行(interpret)，并能调用C库进行拓展。Python有强大的标准库 (battery included)。由于标准库的体系已经稳定，所以Python的生态系统开始拓展到第三方包。这些包，如Django, web.py, wxpython, numpy, matplotlib,PIL，将Python升级成了物种丰富的热带雨林。
今天Python已经进入到3.0的时代。由于Python 3.0向后不兼容，所以从2.0到3.0的过渡并不容易。另一方面，Python的性能依然值得改进，Python的运算性能低于C++和Java(见Google的讨论)。Python依然是一个在发展中的语言。我期待看到Python的未来。
Python从其他语言中学到了很多，无论是已经进入历史的ABC，还是依然在使用的C和Perl，以及许多没有列出的其他语言。可以说，Python的成功代表了它所有借鉴的语言的成功。同样，Ruby借鉴了Python，它的成功也代表了Python某些方面的成功。每个语言都是混合体，都有它优秀的地方，但也有各种各样的缺陷。同时，一个语言“好与不好”的评判，往往受制于平台、硬件、时代等等外部原因。程序员经历过许多语言之争。我想，为什么不以开放的心态和客观的分析，去区分一下每个语言的具体优点缺点，去区分内部和外部的因素。
引自：博客园
一行代码实现人工智能
print (input("我是智能机器人，请输入和我聊天的内容").strip("吗？"))
首先做个总结 ： Python是一门动态解释型的强类型定义语言
了解编译型和解释型、静态语言和动态语言、强类型定义语言和弱类型定义语言这6个概念就可知晓。
编译型和解释型
编译型，其实它和汇编语言是一样的，也是有一个负责翻译的程序来对我们的源代码进行转换，生成相对应的可执行代码。这个过程说的专业一点，就称为编译(Compile)，而负责编译的程序自然就称为编译器(Compiler)。如果我们写的程序代码都包含在一个源文件中，那么通常编译之后就会直接生成一个可执行文件，我们就可以直接运行了。但对于一个比较复杂的项目，为了方便管理，我们通常把代码分散在各个源文件中，作为不同的模块来组织。这时编译各个文件时就会生成目标文件(Object file)而不是前面说的可执行文件。一般一个源文件的编译都会对应一个目标文件。这些目标文件里的内容基本上已经是可执行代码了，但由于只是整个项目的一部分，所以我们还不能直接运行。待所有源文件的编译都大功告成，我们就可以最后把这些半成品的目标文件“打包”成一个可执行文件了，这个工作由另一个程序负责完成，由于此过程好像是把包含可执行代码的目标文件连接装配起来，所以又称为链接(Link)，而负责链接的程序就叫链接程序(Linker)。链接程序除了链接目标文件外，可能还有各种资源，像图标文件、声音文件什么的，还要负责去除目标文件之间的冗余重复代码，等等，所以...也是挺累的。链接完成后，一般就可以得到我们想要的可执行文件了。
解释型，现在再看看解释型。从字面上看，“编译”和“解释”的确有“翻译”的意思，他们的区别在于翻译的时机安排不大一样。打个比方：假如你打算阅读一本外文书，而你不知道这门外语，那么你可以找一名翻译，给他足够的时间让他把整本书从头到尾翻译好，然后把书的母语版交给你阅读；或者，你也立刻让这名翻译辅助你阅读，让他一句一句给你翻译，如果你想往回看某个章节，他也得重新给你翻译。
两种方式，前者相当于我们说的编译型：一次把所有代码朱焕为机器语言，然后写可执行文件；而后这就相当于我们说的解释型：在程序运行的前一刻，还只有源程序没有可执行程序；而程序每执行到源程序的某一条指令，则会有有一个称为解释程序的外壳程序将源代码转换成二进制代码以供执行，总言之就是不断的解释、执行、解释、执行.....所以解释型程序是离不开解释程序的。像早期的BASIC就是一门经典的解释型语言，要执行BASIC。解释型程序中由于程序总是以源代码的形式出现，因此只要有相应的解释器，移植几乎不成问题。编译型程序虽然源代码也可以移植，但前提是必须针对不同的系统分别进行编译，对于复杂的工程来说，的确是意见不小时间的消耗，况且很可能一些细节的地方还要需要修改源代码。而且，解释型程序省却了编译的步骤，修改调试也非常方便，编辑完毕之后即可立即执行，不必像编译程序一样每次进行小小改动都要耐心等待漫长Compiling...Linking...这样的编译链接过程。不过凡事有利有弊，由于解释型程序是将编译的过程放到执行过程中，这就决定了解释型程序注定要比编译型慢上一大截，像几百倍的速度差距也是不足为奇的。
编译型和解释型各有利弊。前者由于程序执行速度快，同等条件下对系统要求较低，因此像开发操作系统、大型应用程序、数据库系统时都采用它，像C/C++、Pascal/Object Pascal(Delphi)、VB等基本都可视编译语言，而一些网页脚本、服务器脚本及辅助开发接口这样的对速度要求不高、对不同系统平台间的兼容性有一定要求的程序则通常使用解释型语言，如Java、JavaScript、VBScript、Perl、Python等等。
但既然编译型和解释型各有优缺点又互相对应，所以一批新兴的语言都有把两者折中起来的趋势，例如Java语言虽然比较接近解释型语言的特征，但执行之前已经预先进行一次预编译，生成的代码是介于机器码和Java源代码之间的中介代码，运行的时候则由JVM(Java的虚拟机平台，可视为解释器)解释执行。它既保留源代码的高抽象、可移植的特点，又已经完成了对源代码的大部分预编译工作，所以执行起来比“纯解释型”程序要快许多。而像VB6(或者以前版本)、C#这样的语言，虽然表面上看生成的是.exe可执行程序文件，单VB6编译之后实际生成的也是一种中介码，只不过编译器在前面安插了一段自动调用某个外部解释器的代码(该解释程序独立于用户编写的程序，存放于系统的某个DLL文件中，所有以VB6编译生成的可执行程序都要用到它)，以解释执行实际的程序体。C#(以及其他.net的语言编译器)则是生成.net目标代码，实际执行时则由.net解释系统(就像JVM一样，也是一个虚拟平台)进行执行。当然.net目标代码已经相当低级，比较接近机器语言了，所以仍将其视为编译语言，，而且其移植程度也没有Java号称的这么强大，Java号称是“一次编译，到处执行”，而.net则是“一次编码，到处编译”。总而言之，随着设计技术与硬件不断发展，编译型与解释型两种方式的界限正在不断变得模糊。
动态语言和静态语言
通常我们说的动态语言和静态语言是指动态类型语言和静态类型语言。
动态类型语言，动态类型语言是指在运行期间才去做数据类型检查的语言，也就是说，在用动态类型 语言编译的时，永远也不用给任何变量指定数据类型，该语言会在你第一次赋值给变量时，在内部将数据类型记录下来。Python和Ruby就是一种典型的动态类型语言，其他的各种脚本语言如VBScript也多少属于动态类型语言。
静态类型语言，静态类型语言和动态类型语言正好相反，它的数据类型是在编译期间检查的，也就是说在写程序时要声明所有变量的数据类型，C/C++是静态类型语言的典型代表，其他的静态类型语言还有C#、Java等。
强类型定义语言和弱类型定义语言
强类型定义语言，强制数据类型定义的语言。也就是说，一旦一个变量被指定了某个数据类型，如果不经过强制转换，那么它就永远是这个数据类型了。举个例子，如果您定义了一个整型变量a，那么程序根本不能将a当做字符串类型处理。强类型定义语言是类型安全的语言。
弱类型定义语言，：数据类型可以被忽略的语言。它与强类型定义语言相反。一个变量可以赋不同数据类型的值。
强类型定义语言在速度上可能略逊色于弱类型定义语言，但是强类型定义语言带来的严谨性能够有效的避免许多错误。另外，“这门语言是不是动态语言”与“这门语言是否类型安全”之间是完全没有联系的！
例如：Python是动态语言，是强类型定义语言(类型安全的语言)；VBScript是动态语言，是弱类型定义语言(类型不安全的语言)；Java是静态语言，是强类型定义语言(类型安全的语言)。
引自： 博客园
· Cpython
Python的官方版本，使用C语言实现，使用最为广泛，CPython实现会将源文件（py文件）转换成字节码文件（pyc文件），然后运行在Python虚拟机上。
· Jyhton
Python的Java实现，Jython会将Python代码动态编译成Java字节码，然后在JVM上运行。
· IronPython
Python的C#实现，IronPython将Python代码编译成C#字节码，然后在CLR上运行。（与Jython类似）
· PyPy（特殊）
Python实现的Python，将Python的字节码字节码再编译成机器码。
· RubyPython、Brython ...
原文：https://www.cnblogs.com/qingjiujun/p/11636499.html